fonthashint patelt has unreliable behaviour

Hi,

The new fonthashint pattern element has unreliable behavior, causing downstream issues related to the not autohinting of unhinted fonts.

As an example, the Google Fonts builder applies a supposed fixing step on unhinted fonts, namely adding a minimal (7-byte) prep table to change the Graphics State scan_control variable in order to turn on dropout control at all sizes.

In effect, this has virtually no change in rendering for almost all practical use cases, and I would not consider a font that undergoes such "fixing" to be hinted: there are no fpgm or cvt tables and no glyph programs!

However it seems fontconfig generates a fonthashint patelt that says it is indeed hinted:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/main/src/fcfreetype.c?ref_type=heads#L2913-2917

As such this false positive makes it not possible to change the autohint patelt on matched fonts.

It also appears, but could be unrelated, that the autofitter is also not called even in light rendering mode.

---

Solution:

I suggest that the fonthashint patelt needs to be a little more reliable by not returning True unless there is at least one of the following: fpgm table found; cvt table found; prep table found and greater than 7 bytes.

I don't think this will cause more than a few false negatives but will definitely cull these idiosyncratic false positives.

---

Repro:

$ curl -Os https://cdn.jsdelivr.net/gh/notofonts/notofonts.github.io/fonts/NotoSans/unhinted/ttf/NotoSans-Regular.ttf
$ fc-query -b NotoSans-Regular.ttf | grep fonthashint
        fonthashint: False(s)
$ gftools fix-nonhinting NotoSans-Regular.ttf NotoSans-Regular.ttf.fix
/scratch/NotoSans-Regular-backup-fonttools-prep-gasp.ttf  saved.
GASP wasn't there
PREP wasn't there
GASP now:  {65535: 15}
PREP now:
        PUSHW[]
        511
        SCANCTRL[]
        PUSHB[]
        4
        SCANTYPE[]
/scratch/NotoSans-Regular.ttf.fix  saved.
$ fc-query -b NotoSans-Regular.ttf.fix | grep fonthashint
        fonthashint: True(s)

$ diff -w <(ttx -l NotoSans-Regular.ttf | grep 0x | sort) <(ttx -l NotoSans-Regular.ttf.fix | grep 0x | sort)
1,13c1,15
<     GDEF  0xA931BCA7      1124    331708
<     GPOS  0x541B948F     86506    332832
<     GSUB  0xA08C60BE     11960    419340
<     OS/2  0x8E158609        96       344
<     cmap  0xBB2E67AF     12760     15976
<     glyf  0xA5A05FC8    242879     44276
<     head  0x282CBBDB        54       220
<     hhea  0x0CB31A9B        36       276
<     hmtx  0x6A198E4F     15536       440
<     loca  0x1E0BD9E9     15540     28736
<     maxp  0x0F4F016C        32       312
<     name  0xA182C53D      1510    287156
<     post  0xD2D96603     43040    288668
---
>     GDEF  0xA931BCA7      1124    331756
>     GPOS  0x541B948F     86506    332880
>     GSUB  0xA08C60BE     11960    419388
>     OS/2  0x8E158609        96       376
>     cmap  0xBB2E67AF     12760     16008
>     gasp  0x00000010         8    331748
>     glyf  0xA5A05FC8    242879     44316
>     head  0x283773DC        54       252
>     hhea  0x0CB31A9B        36       308
>     hmtx  0x6A198E4F     15536       472
>     loca  0x1E0BD9E9     15540     28776
>     maxp  0x0F4F016C        32       344
>     name  0xA182C53D      1510    287196
>     post  0xD2D96603     43040    288708
>     prep  0x68068C85         7     28768

I should have commented what the diff says.

The offsets change because gasp and prep were added, gasp having 8 bytes and prep having 7 bytes.

The head checksum changed because of the modification date; all other checksums are preserved.

In all everything is the same - an unhinted font.

Thank you for reporting. I'll take a look.

mentioned in commit tagoh/fontconfig@e8fc0065

mentioned in merge request !331 (merged)

closed with commit 5e058033

closed with commit e8fc0065

Fixed in git. I see few difference after applying but it may be a false positive.

mentioned in issue freetype/freetype#1320