[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ft-devel] Broken EBDT and kern/hdmx, GPOS (Re: what old/new FontVal say
From: |
Hin-Tak Leung |
Subject: |
[ft-devel] Broken EBDT and kern/hdmx, GPOS (Re: what old/new FontVal says about these fonts (Re: FreeType unable to open some fonts which can be opened by some font viewers (Re: Freetype-devel Digest, Vol 143, Issue 9))) |
Date: |
Fri, 30 Dec 2016 12:08:45 +0000 (UTC) |
Werner: please have another look at 15.ttf and 26.ttc if you are not already
planning to revisit the EBDT situation. They still fail in freetype git, I
think.
I had looked at the 6 cases where the rest of FontVal fails in full validation
mode, before it gets to drive either freetype or the 1.0 backend. If you skip
testing all tables and go directly for driving the backend, only 1 fails -
24.ttc, which seems to be truncated but the first member font seems intact.
(even if you skip all the tests, FontVal still does some minimum check before
passing to the backend - anyway, fixed in dev code, and retesting soon)
The other 5 cases are: 2.otf, which have broken GPOS, 5 and 8 with dodgy kern
and htmx , 15.ttf and 26.ttc with broken EBDT .
I also found the identity of 26.ttc - I myself already have an identical
version (table checksums, etc) with an additional DSIG table. It is
Microsoft's. So it needs to work in freetype :-).
The current version of it in vista+ no longer have this problem afaic, but the
broken and extremely large EBDT can cause FontVal to try to allocate 10+ GB of
memory (and failing) to analyse it. Ditto with 15.ttf . It looks like also
FontVal wasn't written to analyze large EBDT - I needed to rewrite a part of
the EBDT analysis code to not run out of memory while analyzing. EBDT/EBLC are
so complicated. Seems the format was designed very strangely...
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [ft-devel] Broken EBDT and kern/hdmx, GPOS (Re: what old/new FontVal says about these fonts (Re: FreeType unable to open some fonts which can be opened by some font viewers (Re: Freetype-devel Digest, Vol 143, Issue 9))),
Hin-Tak Leung <=