[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]

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...