horizontal font extent disagreements between ft/ot funcs for mongolian/phags pa.

[HinTak]

The font extents reported by the ft/ot versions don't agree:

db3fff0f1319dbf4c5bd06b549c98775 monbaiti.ttf

ft:

ascender/descender/line_gap= 1792 -512 64
h ascender/descender/line_gap= 1792 -512 64

ot:

ascender/descender/line_gap= 1729 -449 184
h ascender/descender/line_gap= 1729 -449 184

e06492ecfcdc5990647fb2c4058778f5  phagspa.ttf

ft:

ascender/descender/line_gap= 2176 -512 -64
h ascender/descender/line_gap= 2176 -512 -64

ot:

ascender/descender/line_gap= 2138 -482 0
h ascender/descender/line_gap= 2138 -482 0

In both of these cases, hb-view seems to be using the ot numbers, although I cannot seem to find out where it switches. At line 690 of util/options.cc, it defaults to the first entry, which is ft if harfbuzz can find freetype.

    set_font_funcs = supported_font_funcs[0].func;

[HinTak]

Supposedly both get the values from hhea. I decompiled the hhea table from the first font, and the ot values are there. So somehow the ft version is returns values not from hhea.

[HinTak]

It appeared the FT values has been moved down or up to the next multiple of 64

[behdad]

Yeah this is a known issue. I thought we didn't hinting and that should do it. Are you testing with recent FreeType?

[HinTak]

I am using ft 2.9.1 (the current latest release).

Were you asking if I am testing against freetype git head? I am staying off freetype git head until GSoC wrapped up and settling, I think.

[khaledhosny]

Check the OS/2 table, it is possible that FreeType or HarfBuzz is reading the values from it rather than from hhea. Last I checked, FreeType had some heuristics to decide which table and which set of values to use, not sure of OT functions use the same heuristics or any at all.

[HinTak]

I looked at the FreeType side - it is supposedly hhea then OS/2. The values look like they were clipped to one direction to multiple of 64, so I am inclined to think Behdad is right in saying it is probably some sort of hinting, or "fit to grid" issue somewhere.

[behdad]

In both of these cases, hb-view seems to be using the ot numbers, although I cannot seem to find out where it switches.

hb-view uses cairo's numbers, which are proper numbers, not hacked-up use of FreeType.

[behdad]

I looked at the FreeType side - it is supposedly hhea then OS/2. The values look like they were clipped to one direction to multiple of 64, so I am inclined to think Behdad is right in saying it is probably some sort of hinting, or "fit to grid" issue somewhere.

Yeah, I'm certain that's what's happening. Never figured out why even though we turn all hinting off. Maybe FreeType always rounds font extents?

@lemzwerg

[HinTak]

The two sets of font extent functions also do wildly different things for ukai from freedesktop.org .

[behdad]

The two sets of font extent functions also do wildly different things for ukai from freedesktop.org .

Care to paste numbers? And link to font?!

[KrasnayaPloshchad]

The links to font are available here:
https://www.freedesktop.org/wiki/Software/CJKUnifonts/Download/
However all download links were no longer works. But I saw ReactOS Forum has a topic for this, so I think you are able to get and test:
https://www.reactos.org/forum/viewtopic.php?f=30&t=15793&sid=5859b3899e47ddf36b0ab0f9f82759ad

[HinTak]

@behdad : heehee, I found that you were in the last discussion about metrics rounding in freetype in 2006 and its effect on pango. You just forgot :-). It is #327852 on Gnome Bugzilla.

If you pull

#1363

You can close this.

[lemzwerg]

Since the issue obviously caused confusion it's probably necessary to improve FreeType's documentation. Any patches are highly welcomed!

[HinTak]

The issue is just that harfbuzz does not consider entities as F26.6's. It sets FT_Char_Size to (F26.6) upem and hopes mistakenly that everything is then in upem. Some FT values are rounded to whole pixels in F26.6. Back in 2006 somebody wanted those numbers in fractional pixels. Pango broke, and it was reverted back to rounding to whole pixels. I suppose FT documentation could emphasize that some numbers are in whole pixels in F26.6 ... I'll think about where that can go.

[HinTak]

The FT documentation did say they are rounded. Also src/hb-ft.cc near the top mentions that harfbuzz is abusing this... ... such that no rounding etc happens was a wrong assumption:

 *   - FreeType works in 26.6 mode.  Clients can decide to use that mode, and everything
 *     would work fine.  However, we also abuse this API for performing in font-space,
 *     but don't pass the correct flags to FreeType.  We just abuse the no-hinting mode
 *     for that, such that no rounding etc happens.  As such, we don't set ppem, and
 *     pass NO_HINTING as load_flags.  Would be much better to use NO_SCALE, and scale
 *     ourselves.

I'd say just pull #1363 and be done.