Roundtripping Oswald Light crashes Silverlight plugin

[ziriax]

I noticed that the Oswald Light font from Google Fonts crashes the Silverlight plugin.

When using the font version from http://www.fontsquirrel.com/fonts/oswald, it works fine.

When roundtripping the fontsquirrel font using TTX, Silverlight crashed again.

[anthrotype]

roundtripping the Oswald font in TTX only fixes some glyphs bounding boxes and sets a corresponding flag in the head table, but I don't think this is the cause of the problem.

I don't know how to test the silverlight plugin with the font...

[ziriax]

My gut feeling: it has to do with TTFAUTOHINT in combination with TTX?

I will make a mini git repo for it as soon as I can

[ziriax]

I added a test project to reproduce the issue here.

Please feel free to ask any questions if you have troubles with it.

[anthrotype]

@ziriax thanks for setting that test repository.
This appears to be the same issue as #335
We closed the issue because we concluded it was a Windows 7 bug, affecting only GDI rendering; and also because we realised that the bug was fixed in subsequent Windows versions.

In issue #335, the font was Amatic, while here it's Oswald. Both were produced using FontForge, and both had one empty (i.e. containing no lookups) OpenType Layout table: in Amatic, it was the GPOS, in Oswald the GSUB.
Now, there seems to be a difference in the way such empty GPOS/GSUB tables are packed by FontForge, on the one hand, and fontTools, on the other. The latter produces a more efficient result, which however seems to be rejected by Windows 7 GDI, and now Silverlight.
Quoting myself:

It seems like a Windows 7 bug which affects only GDI rendering. [...]
I inspected the two GPOS tables, as generated by FontForge and fontTools/TTX, using a hex editor. The size of the latter shrinks from 48 to 36 bytes, because fontTools points the two ScriptRecords to the same ScriptTable and (empty) FeatureList and LookupList structs, instead of repeating them twice like FontForge does. This is perfectly legal by the OT spec

I'm tempted to say again that this is a Windows/Silverlight bug.
The way I would fix the TTX roundtrip issue with Oswald font is just to get rid of the empty GSUB table (simply dump the font with ttx -x GSUB Oswald-Light.ttf and recompile the TTX).
Then the font will be loaded by Windows and, I presume, by Silverlight as well.

[anthrotype]

I wonder if there's any requirement written somewhere to always have both the GSUB and GPOS tables as a pair, even if one of the two doesn't contain any lookups...
I'm not familiar with FontForge, but from what I see in these two examples (Amatic and Oswald), what FontForge seems to be doing is to always include the other table, even when empty, and also write the full list of ScriptRecords, despite these have no evident utility.

I also noticed that a truly empty GSUB table, i.e. also stripped of the ScriptRecords, will not be rejected by Windows 7 Font Preview when roundtripped with TTX.

<GSUB>
    <Version value="1.0"/>
    <ScriptList>
      <!-- ScriptCount=0 -->
    </ScriptList>
    <FeatureList>
      <!-- FeatureCount=0 -->
    </FeatureList>
    <LookupList>
      <!-- LookupCount=0 -->
    </LookupList>
  </GSUB>

Any comments? /cc @behdad @brawer @twardoch @djdm

[khaledhosny]

IIRC, Uniscribe requires both GSUB and GPOS to be present, so that is probably why FontForge is generating an empty table.

[anthrotype]

Ah, thanks Khaled!
So how would you recommend an empty GSUB or GPOS table to look like?
Would it be enough for Uniscribe to have an empty table like the one I posted previously (without no scripts, features nor lookups)?

[khaledhosny]

I don’t know really, it is just some vague recollection. One needs to just test this and see what works with Uniscribe (or try to dig up FontForge sources, but the former might be simpler).

[ziriax]

Maybe related to:

http://sourceforge.net/p/fontforge/mailman/message/4909509/

[anthrotype]

I found an old post on the FontForge-devel list by George Williams:

http://sourceforge.net/p/fontforge/mailman/message/4909509/

In 2005 he submitted a patch to work around a Uniscribe bug whereby some Hebrew GPOS mark-to-base would only work if the font also contained a (possibly empty) GSUB table with a entry for script 'hebr'.

Williams quotes a reply by Sergey Malkin (Microsoft) on the OpenType mailing list:

From: Sergey Malkin sergeym@...
To: Multiple recipients of opentype opentype-list@...
Subject: [OpenType] Re: GPOS behavior affected by GSUB
Date: 09 Feb 2005 13:21:23 -0800

Each shaping engine in Uniscribe can decide on its requirements for
layout tables - some of them require both GSUB and GPOS, in some cases
any table present is enough, or it can work without any table.

Sometimes, purpose of the check is to determine if font is supporting
particular script - if required tables are not there font is just
rejected by this shaping engine. Sometimes, shaping engine can not just
reject the font because there are fonts using older shaping technologies
we still have to support, so it uses some logic when to fallback to
legacy layout code.

In your case this is Hebrew, where both tables are required to use
OpenType processing. Arabic requires both tables too, Latin requires
GSUB to execute GPOS. But in general, if you have both tables you should
be safe with any script to get fully featured OpenType shaping.

Thanks,
Sergey

So it seems like the safest approach with Uniscribe would be to always have both tables, with all the same scripts referenced in both.

Anyway, the problems still remains as to the way fontTools re-compiles these almost-empty GSUB/GPOS tables (which have no features/lookups but do contain some script records). After roundtripping them with TTX, the fonts can't be even rendered by some windows 7 apps (such as the built-in Font Preview), let alone shaping..

[anthrotype]

@ziriax you beat me!

[ziriax]

LOL! No no, all credits go to Google's search engine :-)

[behdad]

This should be fixed now. Please reopen if it's not.

@rsheeter @garretrieger We might need to recut a few Google Fons...

[anthrotype]

That was quick!
Although, you have fixed issue #518 which had to do with subsetter, whereas this has to do with the way such semi-empty GSUB/GPOS tables (eg. containing only script records) are packed by fontTools into the final binary OTL tables.
You have patched the subsetter, but in order to fix the current issue (i.e. decompile/recompile those tables breaks them under Windows 7) we need to address it in otBase.by or somewhere around that.

[behdad]

Humm. Ok, let me give that one a try as well.

[anthrotype]

basically, we need to replicate byte-to-byte the way FontForge or MS Volt compiles these semi-empty tables, otherwise Windows 7 won't be happy.

You can grab Oswald-Light from here:
http://www.fontsquirrel.com/fonts/oswald

If try to roundtrip the font with ttx, you'll notice that the size of GSUB shrinks from 80 bytes in the original to 48 bytes in fonttools.

If you have a Windows 7 machine at hand, you'll see that Windows font preview will refuse to show the roundtripped font, whereas it loads the original just fine. It appears that only the GDI renderer is broken. In fact, if you install the font in C:\Windows\Fonts and load it, say, with the latest MS Word (which uses DirectWrite), the rountripped font will still work. I also tested on Windows 8, and the bug seems to be resolved there.

[behdad]

Can you try again?

[anthrotype]

I roundtripped Oswald-Light.ttf with ttx and now it works in Windows 7!
Thanks Behdad 💯

[behdad]

Excellent!

[anthrotype]

this was really a weird bug!

[moyogo]

Thanks Behdad!