I'm not the first to get tripped up by this. But I came up with a solution suitable for the cheap & lazy—er, economical & efficient.
For bad and arbitrary reasons, OT/TTF fonts with layout features are only recognized as such in Windows if they have a DSIG (digital signature) table. Without this table, they behave as normal TTF fonts (i.e., none of the layout features work). This is not true of OT/CFF fonts, which need no DSIG table.
Windows customers can use OT/CFF fonts. But MS Office, and MS Word in particular, still works better with TT-based fonts. For instance, for bad and arbitrary reasons, the built-in PDF generator in Word will not embed OT/CFF fonts, only OT/TTF.
To make a DSIG, one solution is to buy an actual digital signature from a certificate authority. Fontlab, for instance, can generate the DSIG table if you have the signature files. (Don't know how it's handled in Glyphs or Robofont.) But this is about $200 per year. Digitally signing your fonts has other ostensible benefits, so if you like that, great. To me, it's a lot to pay just to get OT/TTF fonts to do what they should've been able to do in the first place, which is: work.
FontForge can put in a dummy DSIG table, but that requires dealing with FontForge.
If you have ttx installed, however, you can do it this way:
Create a ttx file with a dummy DSIG table, like so:
<?xml version="1.0" encoding="ISO-8859-1"?>
<ttFont sfntVersion="\x00\x01\x00\x00" ttLibVersion="2.2">
<DSIG>
<hexdata>
00000001 00000000
</hexdata>
</DSIG>
</ttFont>
Then you can merge this into your OT/TTF like this:
ttx -m font.ttf dsig.ttx
This will decompile the ttf, add the DSIG table, and recompile in one step. Then the font will work as intended in MS Office (or so I have found in my testing thus far.) This is also easy to incorporate into other scripts.
Of course, this is not a real digital signature, but it's sufficient to convince Windows that the font has a valid DSIG table.
(Hat tip to Ross Mills for pointing me in the right direction.)
Comments
I'll be curious to learn if this affects web fonts, either in IE or in general.
That's odd. When the table was announced in the 90's, all developers were told that fonts without a DSIG would eventually not work at all on Windows. So, this's a fine compromise.
Perhaps predictably, Word 2010 still doesn't implement the DSIG restriction consistently: OT/TTF fonts without a DSIG will still show their layout features in the preview window of the Character formatting box, but the layout features won't show up in the document itself. This was the moment of infuriation that started my hacking spree.
Despite the infuriations, Word is nevertheless the most popular typesetting program in the world, and with the addition of layout features, it's actually quite capable.
Like income tax.
Also, what happens if you output the word-document-with-OT-features-used — to a web site, does any it display in... Firefox?
In DTL OTMaster one can copy a dummy DSIG table from another TTF, but that requires dealing with DTL OTMaster.
KeyError: 'ulVersion'
when I try to merge the table into the TTF as described above. Is it just me or is anybody else also experiencing that problem?Also check if you need this fix.
Haven't had time to test the resulting fonts to see exactly how viable this is, but it's a start if anyone wants to fork: https://gist.github.com/okay-type/9060558
I'm using a Mac and FontLab and I'm guessing FontLab has to run this ttx script in order to get the dummy DSIG into the TT font? So it should mean I can do that on the Mac and the resulting TTF will work on Windows.
Thanks,
Adrian
But I don't know where/when this gets used..?
ttx -m font.ttf dsig.ttx
Can the process be explained in a simple way listing the actions like this...
This is what I did in Terminal:
Enter which ttx, Return.
Drag ttx app to Terminal (displays the path to the app).
Drag dsig.ttx to Terminal (displays the path to the text file).
Drag SassoBoo.ttx file to Terminal (displays actual TrueType font file path).
Return.
Compiling begins... (result is a dsig.ttf file).
Make a text file containing:
https://us.v-cdn.net/5019405/uploads/FileUpload/44/decaba5c59a35eacd266ec3b1984e5.jpg
1. Launch Terminal.
2. Type ‘which ttx’, Return:
/usr/local/bin/ttx adrians-imac:Dsig fldr adrianshome$
3. Drag TTX app to Terminal (since it accepted your Dsig fldr snippet):
/Users/adrianshome/Downloads/fonttools-2.4/Tools/ttx
4. Type: -m (not forgetting a space after the m).
/Users/adrianshome/Desktop/Dsig\ fldr/SassoBooIta.ttf /Users/adrianshome/Desktop/Dsig\ fldr/dsig.ttx
First remove all of the dsig#.ttf files in the Dsig fldr if there are any.
Then for each font file:
5. Drag the ttf font file to terminal (say SassoBoo.ttf)
6. Drag dsig.ttx to terminal
7. Return
That will compile only dsig.ttx, merge the DSIG into SassoBoo.ttf and produce a file named dsig.ttf in the Dsig fldr, so now…
8. Rename dsig.ttf as SassoBoo something.ttf (the original TrueType filename)
There are much better ways to proceed using scripts.
Don't switch steps 3 and 4. You need to put the .ttf file before the .ttx file.
Yes, I've re-installed AFDKO 2.5 version 63782. Now, $PATH is is different from the
A large 1.1Mb file gets dumped in the Dsig fldr and Terminal gets errors perhaps because its trying to access a version of ttx.py in the Python Folder...?
etc.
So why are echo $PATH and the resulting path different?
BTW, why is the <code> appearing in separate lines? How do I format it so its all in one piece?