Re: [ft-devel] what old/new FontVal says about these fonts

[Hin-Tak Leung]

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 <address@hidden> 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