[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] maxp.maxStackElements (e: Freetype-devel Digest, Vol 141,
From: |
Hin-Tak Leung |
Subject: |
Re: [ft-devel] maxp.maxStackElements (e: Freetype-devel Digest, Vol 141, Issue 4) |
Date: |
Sun, 9 Oct 2016 20:59:47 +0000 (UTC) |
Slight correction, s/fpgm/fpgm or cvt/ .
I can get FontVal 2.0 to match the behavior of FontVal 1.0 regarding
maxStackElements and stack overflow errors, on all the fonts I mentioned below
- or if you wish, get freetype to match that of MS rasterer's, by taking the
+32 off, with the following differences:
- I can't see how the MPPEM instruction can overflow in FreeType, but it can
with the MS rasterer (according to FontVal 1.0 against font-mfizz.ttf ). So it
looks like that instruction is implemented differently.
- FreeType won't load 'Apple Color Emoji.ttf' at 10pt, and does not overflow at
40pt.
- FreeType seems to load the cvt twice, so all messages from overflow in cvt
happens twice. This is annoying, but not IMHO a big issue since well-behaving
fonts don't get them, and if you as a font designer getting every error message
twice, it might be stronger incentive to fix it :-).
Given the first issue - that some instructions are implemented differently - it
is probably wise that one should add a few on top just to allow one's font to
work on different rasterers... (assuming some rasterer actually take the font's
value as is, on trust...)
--------------------------------------------
On Sun, 9/10/16, Hin-Tak Leung <address@hidden> wrote:
Hi Cosimo,
It is 32 extra elements - elements are minimum 16-bit wide?
FreeType probably use 32-bit int's for it.
I checked my test results of the ~5000 fonts I tested for
E6045 ( the "open font" part is up at
http://htl10.users.sourceforge.net/tmp/FontVal-test-results-2016July/
) - the FontVal code for stack overflow.
You can do something like
bzip2 -dc fedora-1.0-texlive.txt.bz2|
grep E6045
to extract that entry yourself
Because of the +32, E6045 is not seen with FontVal 2.0
at all. (I'll fix it one day...)
But a few fonts can trigger that with FontVal 1.0. They are
/usr/share/texlive/texmf-dist/fonts/truetype/public/fontmfizz/font-mfizz.ttf
from texlive-fontmfizz-svn35892.0
DecoTypeNaskh.ttf and Apple Color Emoji.ttf from apple
(various versions)
and a few *-*-hkscs-u.ttf CJK fonts from my private stash.
You can probably play with either the two apple fonts or the
mfizz font from texlive a bit, move the value up and down a
bit to see what FontVal 1.0 thinks is the correct answer.
BTW, all of the flagged errors from FontVal 1.0 happens in
the fpgm! So you need to make sure that you are processing
fpgm correctly.
I'd be interested if you can say, modify any of those fonts
to get FontVal 1.0, FontVal 2.0 (taking the +32 into
account) and VTT into some sort of agreement.
Hin-Tak
- Re: [ft-devel] maxp.maxStackElements (e: Freetype-devel Digest, Vol 141, Issue 4), Hin-Tak Leung, 2016/10/08
- Re: [ft-devel] maxp.maxStackElements (e: Freetype-devel Digest, Vol 141, Issue 4), Hin-Tak Leung, 2016/10/08
- Re: [ft-devel] maxp.maxStackElements (e: Freetype-devel Digest, Vol 141, Issue 4), Hin-Tak Leung, 2016/10/09
- Re: [ft-devel] maxp.maxStackElements (e: Freetype-devel Digest, Vol 141, Issue 4),
Hin-Tak Leung <=
- Re: [ft-devel] maxp.maxStackElements (e: Freetype-devel Digest, Vol 141, Issue 4), Hin-Tak Leung, 2016/10/11