OTF fonts from Glyphs not working with Windows/Word

James Puckett

I’m investigating problems with a font of mine, produced with Glyphs, that inexplicably works in Windows and Word (for Mac) when it’s a TTF font but not when it’s an OpenType font. Specifically I’m talking about layout issues—problems with kerning, spacing, OT features, or text turning to garbage. I’ve noticed a series of complaints around the web about fonts from Glyphs having problems with kerning and spacing in Word. I’m concerned that this might be a bigger problem than just Word being flaky about kerning.

Has anybody else had this problem? If you’ve had problems with kerning and OT features in Windows and/or Word in an OTF font have you tried using a TTF font to see if that worked? If so, what happened?

Hin-Tak Leung

Is your opentype font with truetype outlines or postscript (CFF) outlines? Well-known fact: Microsoft's rasterer for CFF is poor (or was...). Somebody from Microsoft can correct me

James Puckett

Is your opentype font with truetype outlines or postscript (CFF) outlines?

The OTF font is Postscript, the TTF fonts is TrueType. I’m just using the common names because not everybody knows what CFF is.

Well-known fact: Microsoft's rasterer for CFF is poor (or was...).

I’d rather not get into a conversation about the subjective quality of text rasterizers. I’m asking about layout problems, so I’ve edited my original post to make that clear.

John Hudson

Does the OTF have a DSIG table? This can be necessary to get Word to recognise that it is a font that might have OTL features. The DSIG table can be a stub: you don't need to actually have a digital signature. You can add a stub DSIG table with TTX or OTMaster.

James Puckett

How do I add the DSIG with OTMaster? The manual only explains how to cut a signature out of a file.

LeMo aka PatternMan aka Frank E Blokland

Hi James,

You can just copy and paste a (dummy) DSIG table from another font. AFAIK one can generate dummy DSIG tables with FontForge.

James Puckett

Thanks. I tried adding a stub DSIG with TTX using instructions Ben Kiel posted in a different thread. Sadly my Devangari is still broken in Wordpad. Not sure about other people’s Word problems, I’ll talk with them and report back.

John Hudson

Sadly my Devangari is still broken in Wordpad.

Devanagari shaping broken? That shouldn't be an issue at all, regardless of format or presence/absence of DSIG, because it should be passed to the Indic shaping engine. I've got plenty of CFF Indic fonts that work just fine in Wordpad, Word, etc., even without DSIGs.

James Puckett

Devanagari is broken when I generate my Rhodium font as an OTF file. It mostly works as a TTF, with the exception of Reph sometimes being displayed as halant+r. Here’s a screenshot of text from BBC Hindi in Wordpad on Windows 10. Note how some sections turn into garbage. And this example is fairly well-behaved. I’ve also sometimes seen it not process any conjuncts at all, and copy/pasting text set with the font results in pasted text turning to garbage.


 

A few minutes ago Rhodium, with the DSIG added to the OTF, was working fine after a reboot. So I deleted some old broken versions of the font (they all have different family names to prevent caching trouble) and rebooted. Now it’s broken again.

I’ve been over this many times and can’t see any big difference between the TTF and OTF files. Glyphs puts a few kerns in different places in the feature file, but otherwise the OpenType features going into the fonts are the same. And it works fine in Chrome on Mac and and in Creative Suite.

John Hudson

Are you running Windows on a PC, or as a virtual machine on a Mac?

Either way, it sounds like this could be a corrupt font database, and the best thing to do is restart Windows in recovery console mode. In the console, navigate to the Windows/Fonts folder, and delete all entries for the Rhodium font. Then navigate to Windows/System32 and delete the 'FNTCACHE.DAT' file (not the .dll). Then restart Windows. The font cache .dat file will be rebuilt, and then you can reinstall a clean copy of the Rhodium font and see if it behaves. [Don't worry if you still get a message saying the font is already installed: at that stage Windows is lying to you.]

Dave Crossland

I use "ttx -s" and http://meldmerge.org to compare fonts by hand. 

James Puckett

I removed all the Rhodium fonts and cleared the cache on my PC and I also tested with a fresh VM. Rhodium remains broken on both.

Belleve Invis

What's these metadata in your font?

• OS/2.ulUnicodeRange(1-4)
• OS/2.ulCodePageRange(1-2)
• OS/2.fsSelection
• OS/2.PANOSE

Some Office applications REALLY care about them, though other programs do not.

Belleve Invis

I regenerated your Rhodium Libre with Fontforge in CFF OTF with a dummy DSIG, and it works just well in Word. So I think maybe it is just because that Wordpad DOES NOT SUPPORT complex scripts?

John Hudson

So I think maybe it is just because that Wordpad DOES NOT SUPPORT complex scripts?

Wordpad definitely DOES support complex scripts. Any Windows app gets complex script support via system text APIs.

It's a good idea to test in NotePad, by the way, because this provides the most direct connection between the font and the Uniscribe Indic shaping engines, independent of other text layers that may be involved in Word and Wordpad. If the font fails in NotePad, that's a strong indication that there is something wrong with the font.

James Puckett

I don’t get garbage in Notepad, but the layout is still broken. 

Does it make sense to test Deva by breaking the font down into subsets? For example, a font with just the consonants and vowels, then add matras and test those, then add and test half forms, and so on?

John Hudson

Have you tried copying the GDEF, GSUB and GPOS tables from the TTF that works directly into a CFF font, bypassing the OTL generation as part of the CFF production? That will determine if the error is in the generation of those tables when the CFF font is exported from your tool (Glyphs?).

Also see Belleve's not regarding Unicode range and Codepage bits in the OS/2 table. It's a good idea to claim at least one complete codepage supported in the font (usually CP1252), even if the font actually contains only Devanagari characters. This is the reason all the non-Latin fonts we make for Microsoft contain a Latin subset.

Belleve Invis

John Hudson said:

So I think maybe it is just because that Wordpad DOES NOT SUPPORT complex scripts?

Wordpad definitely DOES support complex scripts. Any Windows app gets complex script support via system text APIs.

It's a good idea to test in NotePad, by the way, because this provides the most direct connection between the font and the Uniscribe Indic shaping engines, independent of other text layers that may be involved in Word and Wordpad. If the font fails in NotePad, that's a strong indication that there is something wrong with the font.

Well in my experiments, even if the Rhodium is not installed I cannot paste any Devanagari text into it. So I really think that it's a bug of Wordpad.

John Hudson

I have absolutely no problem at all with Devanagari or other Indic text in Wordpad. I use it for quick text input and editing of all manner of scripts on a regular basis, also with both TTF and CFF fonts.

John Hudson

What version of Wordpad under what version of Windows are you testing? I'm using Windows 7 (Last That Didn't Suck™).

James Puckett

I have no trouble with other Devanagari fonts in Wordpad. As noted above, the TrueType version of Rhodium is just fine it Wordpad. It is possible that there are some bugs in Wordpad causing problems, but if there are they’re probably bugs related to a font being broken in the first place.

James Puckett

What's these metadata in your font?

• OS/2.ulUnicodeRange(1-4)

• OS/2.ulCodePageRange(1-2)

• OS/2.fsSelection

• OS/2.PANOSE

Unicode Ranges: 0x00008007, 0x00000000, 0x00000000, 0x00000000
(Fontlab shows these as Basic Latin, Latin-1, Latin Extended-A, and Devanagari)

Codepages: 0x20000093, 0x00000000
(Fontlab shows1252 Latin 1, 1250 Eastern Europe, 1254 Turkish, 1257 Windows Baltic, and Macintosh Character Set)

fsSelection: 0x0040
(Regular according to OTMaster)

PANOSE: All are 0x00 except panose b.weight, which is 0x05

LeMo aka PatternMan aka Frank E Blokland

FWIW, I used OTM to export the features files from the .ttf and .otf versions, and I imported (recompiled) these in the .otf. Both seem to contain the same GPOS errors (reported in List–>Messages) and after removing these at least the features compile fine.

James Puckett

John Hudson said:

Have you tried copying the GDEF, GSUB and GPOS tables from the TTF that works directly into a CFF font, bypassing the OTL generation as part of the CFF production? That will determine if the error is in the generation of those tables when the CFF font is exported from your tool (Glyphs?).

Just tried this, still broken.

James Puckett

Frank, would you please post your fixed feature file? I fixed the syntax errors and and now OTM crashes when I try to import it. Mine is attached, I had to add the .txt extension to get the forum to attach it.

John Hudson

Just tried this, still broken.

Okay, at least that rules out the possibility of corruption in the CFF version's OTL tables being responsible. Start doing comparisons of other tables between the TTF and CFF versions, looking for discrepancies. I'd start with the OS/2 table and cmap table.

LeMo aka PatternMan aka Frank E Blokland

I fixed the syntax errors and and now OTM crashes when I try to import it.

OTM crashed while importing your adapted features file over here too. This will be investigated, of course. The lines that seem to cause the damage are:

 pos [ \uni091C094D]
       [ \uni091C094D091E \uni091C094D091E0930 \uni091C094D091E094D] <0 0 8 0>;
 pos [ \uni0923094D]
       [ \uni091E \uni091E0930 \uni091E094D] <0 0 25 0>;

I simply removed the lines that were indicated by OTM as error while compiling. I will send you the features file directly and I have also included an .otf of your font generated with GlyphMaster (using the stripped features file) for comparison (I renamed it accordingly). The encoding should be identical to the one in your original font.

James Puckett

Thanks, Frank. I’ll be working on this again Monday and I’ll report back after.

Georg Seifert

I had a look at the file. For me, neither the TrueType nor the CFF based version worked. removing the `aalt` feature fixed it. I need to look into it more but a first look at files with ttx showed a lot differences in the lookup structure if I have a aalt feature with one substitution or not. I need to look into this more. And I read on another thread that the aalt feature is not so important nowadays.