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?
0
Comments
The OTF font is Postscript, the TTF fonts is TrueType. I’m just using the common names because not everybody knows what CFF is.
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.
You can just copy and paste a (dummy) DSIG table from another font. AFAIK one can generate dummy DSIG tables with FontForge.
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.
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.
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.]
- 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.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.
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?
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.
(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
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.
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.