Happy New Year to you all too. The full-ish reports (notes below) of the 29 fonts, plus the 1.0-backend part are in: http://htl10.users.sourceforge.net/tmp/2017-Jan-broken-29-reports.tar.xz
It is under 2MB but will expand to about 180MB, btw. The xml's are the original, but the derived html's may be more convenient for viewing. There are some known issues with the xml->html transform so it is possible some info is missing in the html version. Let's me know if that's the case other than the &x0;'s in 14 and 24. Note: missing from 6 of the reports are the reasons why I had to change the C# side of things (they are added after the reports were generated - but I don't want to re-run as e.g. 15.ttf takes about 10 hours to run, and a few of the others about 2 hours). 15.ttf, 26.ttc: rather broken EBDT 24.ttc: only member 0 seems to be mostly intact; the report should say member 1+ onwards are broken, instead of showing blank in the tar ball. 2.otf: broken GPOS which also affects verification of some fields in OS/2 5.ttf, 8.ttf: rather broken kern table In terms of critical errors, the old 1.0 backend only have these: 15.ttf: Point out of range 22.ttc: Negative seek 26.ttc: TrueType stack underflow 6.ttf: Error reading from font, bad offset or length while late 2.7 (just before 2.7.1) have these: 14.ttf: Horizontal metrics (hmtx) table missing 15.ttf: Unknown file format 26.ttc: Unknown file format 6.ttf: Broken file 22.ttc is another case of a ttc, apart from 24.ttc, where some of the member fonts are okay which others broken - according to the old 1.0 backend, member zero seems to have a broken head table (before it gets to the backend), member 1 fails with Negative seek, but member 2 is a pass. To save running time (it helps to get 26.ttc from over 10 hours down to 2!), I have changed the FontVal code to not repeat if later glyf in a ttc is identical to member zero's, so I don't know how current freetype behaves for member 1 or 2 for 22.ttc . Probably a fail, pending Werner's last 'Volunteers welcomed!' comment :-). I wonder whether I should hook up the incremental loading stuff to get 14.ttf to work with the new backend - afterall, the rest of FontVal already checks hmtx, and the hinting/rastering backend don't really need to care about advance widths perhaps. Although that's unusual usage of Freetype, but ghostscript already uses freetype that way. Lastly I think this was mentioned before: 15.ttf, 26.ttc have rather broken EBDT's so they fails with FreeType rather early, but the 1.0 backend can go a lot further; and 26.ttc is mostly an old authentic microsoft font (with DSIG removed but otherwise identical), so FreeType could try a little harder... -------------------------------------------- On Sun, 1/1/17, Werner LEMBERG <[email protected]> wrote: A happy new year to all of you! > I am down to 1 file difference - 14.ttf. The hmtx table is > missing/mis-spelt alright. That does not seem to stop the FontVal > 1.0 backend loading the glyf and check rasterization/hinting. I > tried by-passing that check in freetype - it seems that it is > possible to cope from incremental loading? but I did not get ftdump > to run. fails with 0002 - unknown file format? I've finally decided to not support outline TTFs that are missing the `hmtx' table. Theoretically it would be possible to extract the advance width (both unscaled and hinted) from the two horizontal phantom points, but this would need a major coding effort, I guess, and it's not worth the labour for broken fonts. > Also, I wrote 'fully' - type face 0 in 24.ttc seems to be mostly > intact . That may be why some other viewer can use it. Any chance of > making that work a little better? There was actually a bug: For TTCs, FreeType inspected face index N+1 while requesting named instance information for index N. A side effect was that FreeType tested face index 1 to check whether the TTC is valid. Fixed now. FreeType now tests face index 0 – this makes font 24.ttc work. A further improvement to handle broken fonts would be to loop over all TTC header entries to find valid subfonts (cf. `sbit_strike_map' in `sfnt_load_face' that eliminates invalid strike entries), but I'm too lazy to do that. Volunteers welcomed! Werner _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
