Re: [ft-devel] The KaiU.ttf anomaly.

[Werner LEMBERG]

> It is not possible to toggle hinting with either MingLiU or KaiU in
> ftview, right?

Correct.  However, it is possible in FreeType to get unhinted `tricky'
glyphs by setting both FT_LOAD_NO_HINTING and FT_LOAD_NO_AUTOHINT
while loading a glyph.  To view the unhinted glyphs you might use
FontForge – only in a debugging session the bytecode is applied.

> I seems to remember many years ago before hinting was
> implemented/enabled, they looks very bad - now that I understand
> hinting a lot more, I think the problem with them is that they do
> very "creative" use of hinting to do extremely large pixel movement
> to move stems into positions (instead of just the half-pixel's for
> hinting in other fonts), and therefore does not work at all without
> hinting.  Is my understanding correct?

Not really.  It's rather that tricky fonts provide a set of elements
(i.e., subglyphs), and the hinting code scales and shifts the elements
as needed.  This greatly reduces the size of the font, since almost
all CJK gyphs are composites, and its associated bytecode is quite
small also.

> [...] the most timing consuming font is kaiu.ttf at 7 hours, above
> all the other CJK fonts, including font collections,

I see two reasons why this happens.  Firstly, due to using glyph
components, the number of points in a composite glyph tends to be far
larger than in fonts that don't have overlapping glyphs.  Secondly, by
the same token, the number of bytecode instructions to execute are far
higher since each component comes with its own bytecode.


    Werner