FreeType check?

[miguelsousa]

Has a check that validates that a font can be rasterized by FreeType been considered already?

I'm asking because AnchoGX.ttf version 1.000 (from http://beatrizl.com/project/ancho) crashes freetype-py v2.2.0.
fontview v0.3.1 also doesn't render it, I assume because of a FreeType failure.

import freetype
face = freetype.Face("AnchoGX.ttf")
face.set_char_size(48 * 64)
face.load_char('S')
bitmap = face.glyph.bitmap
print(bitmap.buffer)

The snippet above crashes with this error,

freetype.ft_errors.FT_Exception: FT_Exception:  (too many function definitions)

And Rubik-Italic.ttf crashes with,

freetype.ft_errors.FT_Exception: FT_Exception:  (stack overflow)

[felipesanches]

It would be nice to gather more info about this crash and also report it to the FreeType dev team.

[miguelsousa]

So far, FreeType is the only tool I found that cannot handle these fonts. I'll open an issue at freetype-py.

[felipesanches]

This specific error message means that the hinting code on this font exceeded freetype limits.

https://github.com/servo/libfreetype2/blob/f801061ee57dac0937cccffb0f7bf3fa120208f5/freetype2/src/truetype/ttinterp.c

[miguelsousa]

The feedback on the linked issues suggests that the fonts are malformed.

@felipesanches I'm interested in adding a FreeType check; it will have a dependency on freetype-py. Do you have any preference on which profile it should go into, and any guidance on how to implement it?

[josh-hadley]

Chiming in with my vote for this also (and willingness to help implement). Considering the widespread use of FreeType, I think it would be helpful to have a check that actually exercises fonts in the rasterizer. Worth noting too that other implementations that appear to work are probably just silently failing and attempting to continue using the malformed font while skipping bad glyphs/hints/etc.

[felipesanches]

@felipesanches I'm interested in adding a FreeType check; it will have a dependency on freetype-py.

That's OK.

Do you have any preference on which profile it should go into?

Sounds like a check for the universal profile ;-)

and any guidance on how to implement it?

I'm not sure. A long time ago there was a check that relied on a fork of MSFontValidator that tapped into a patched freetype that exposed those hinting bytecode errors. But it was very unpleasant to work with these patched dependencies. Not sure if you are planning to do something similar to that, or if you have something else in mind.

Anyway, I'll surely be glad to review a pull request and offer you some guidance if there's anything in our codebase you need help with.

[HinTak]

FWIW, exc->maxFDefs is read from the font's maxp table. The freetype message just indicates the font is broken, in that some of values in its maxp table is just wrong (too low). It is not a freetype limit, it is just a wrong number in the font itself.

[HinTak]

@miguelsousa the Microsoft documentation is quite clear about E6045 about what's wrong with the font and what the corrective action from the font designer is https://github.com/HinTak/Font-Validator/blob/b8394cb446c1c4963e88f6f2242c6847378ca1b0/GenerateFValData/OurData.xml#L5163

[HinTak]

@miguelsousa likewise, the description for E6016 is quite clear that maxp table in the font is wrong.
And what you need to do to correct the font: https://github.com/HinTak/Font-Validator/blob/b8394cb446c1c4963e88f6f2242c6847378ca1b0/GenerateFValData/OurData.xml#L4833 .

This is original Microsoft documentation , written by Microsoft folks - you would see that my only change to this part is documenting how freetype differs from the Microsoft rasterizer in situations where the font is broken in multiple ways.

[HinTak]

@miguelsousa and there is a "official" python binding https://github.com/FontVal-extras/freetype-py to the freetype-pretending-to-be-Microsoft-rasterizer backend.

[miguelsousa]

@HinTak thanks for the info.