[David, please read! Perhaps you can provide fixes? If you need the
particular font for inspection I can send it to you.]
Lars,
sorry for the late reply.
> seems like freetype doesn't like to load the above font (IIRC it's
> part of the arabic fonts for MS Office) when enabling the Bytecode
> interpreter. FT_Load_Glyph always returns an
> FT_Err_Too_Few_Arguments.
It is a problem in the font: The `prep' table is too short, lacking a
final argument to pop from the stack. Your solution of catching
FT_Err_Too_Few_Arguments is a good start, but I consider the current
behaviour of FreeType as buggy; more specifically, the font exhibits
the following two bugs.
. Assuming that Dwnoutsh.ttf loads just fine in Windows, we should
do the same. Similar to other places in FreeType I suggest that
we provide, say, 10 zero-valued arguments on the stack which
buggy fonts can pop safely while handling the prep table. Maybe
we should do the same with other instruction tables too.
. Regardless of using FT_LOAD_FORCE_AUTOHINT, the `prep' and `fpgm'
bytecode tables are always executed, both for initializing the
font and changing the size. This is a serious problem IMHO; for
example, the ftview program can't display Dwnoutsh.ttf at all
exactly for this reason because tt_size_reset always fails.
I'm not sure how to solve that elegantly; we should probably add
an `FT_PARAM_TAG_AUTOHINT' flag so that the bytecode interpreter
stuff can be ignored on a global level for a complete font
(contrary to FT_LOAD_FORCE_AUTOHINT which acts locally on a
single glyph).
David?
Werner
_______________________________________________
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
