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... _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
