[Bug] Cut font

[SeeDborg]

Hi,
I use the font "Marelle" (from : https://marelle.forge.apps.education.fr/) in OpenBoard and some letters are cut in the bottom :

[sebojolais]

In my side, it is like the windows height generates the cropping issue.

Because the border of the text widget follows the cut line :

Now the windows height is calculated automatically with QFontMetrics::height() :
https://github.com/OpenBoard-org/OpenBoard/blob/dev/src/domain/UBGraphicsTextItem.cpp#L413-L415
And QFontMetrics::height() is always equal to ascent()+descent(). have a look at the documentation.
So it is like QFontMetrics does not return the good value for ascent()+descent() with the Marelle font.

I do not know if there is another way to get the real bounding box of the written font ?

[letsfindaway]

I looked at the Marelle font using the xfd tool. It tells me, that the font reports an overall ascent of 24 and descent of 8. But if you select a specific character, e.g. the "f", then it tells that this character has an ascent of 24 and a descent of 16.

So the problem is that the font incorrectly specifies a descent of 8 for the overall font, while individual characters have a larger descent.

I think this problem should be reported and fixed at the font.

[sebojolais]

Hi @letsfindaway ,

Thnak you for your answer, I confirm your test.
I am discussing with the designers and I will be back here.

[RosaWagner]

Hi, font engineer of Marelle here.

The software is using the wrong values to calculate the font bounding box. When the fsSelection bit 7 is enabled (use_typo_metrics), it means that the sTypo metrics are used to calculate the linespacing, and they do not relate to the font's outline. You have to look at the usWin metrics in the OS/2 font table. This is how fonts are engineered since at least 8-10 years.

usWinAscent > Ymax
usWinDescent < Ymin

So it contains also the diacritics etc. This was added in the OpenType format to solve clipping issues on screen

If you normalise values for the sTypo metrics, then, for any font, you might expeience clipping (usually the accents). With Marelle it cuts the descender because the font is made to match the Seyes guidelines, which have a height between two baselines inferior to the height of ascent+descent. But if we want Marelle to get on to all Seyes baselines, then this is the interline space we have to set.

[RosaWagner]

I add here a link to OpenType Spec about the usWin values: https://learn.microsoft.com/en-us/typography/opentype/spec/os2#uswinascent

"Applications that use the sTypo* fields for default line spacing can use the usWin* values to determine the size of a clipping region."

And maybe this as well could be of use? I don't know https://github.com/googlefonts/fontations

[letsfindaway]

Thanks for your detailed and technical answer! OpenBoard is using Qt and Qt is processing the fonts. I looked at the Qt source code and found this:
https://github.com/qt/qtbase/blob/6.10.1/src/gui/text/qfontengine.cpp#L454-L496.

Even if you're not a programmer you might understand what this does:

• It gets the typoXxx and winXxx values from the OS/2 table
• Then based on the flag preferTypoLineMetrics it either uses the one or the other to determine the ascent, descent and leading
• As the flag is set, the typoXxx values are used. And there is no way for us as the application to get the winXxx values, too.

As Qt is a framework used by many application, this also means that no Qt based application has any chance to get the winXxx values.

You see, as an application developer I'm kind of stuck here. I have no means to get the correct value for the line height to avoid clipping.

The following is e.g. happening with LibreOffice Draw:

There is no clipping, but the line spacing is too narrow.

Also a text on Inkscape looks weird:

So it seems that many applications have problems to determine the correct line height and spacing.

[RosaWagner]

Maybe Inkscape uses the UPM size as a base for linespacing. The vertical metrics is a tricky issue, and some don't read the default parameters from the font. But what you see in LibreOffice is the correct lineHeight. I didn't decide what guidelines the teachers use in France. They use this:

and they teach a handwriting where x-height is one line and ascenders go up to 3 lines, unfortunately it induces clashes. I can only set what is currently applied, or double the linespace so text is written on one baseline out of two. But teachers were complaining about that too, because it was too large. So I am stuck too.

I gonna propose to my team if we could generate a "technical" version of the font with higher linespacing that doesn't cut the descenders—but that won't match the teacher's beloved Seyes guidelines.

[letsfindaway]

Now I understand the problem. With Seyes lines you have the same problem. The solution would be to leave one line blank between and after text, just as you did in the example text shown here: https://educajou.forge.apps.education.fr/seyes/

So this could also be the solution for OpenBoard users: Just press once Enter after the text to add a new line, and voila!