Dear TypeDrawers,
I’m about to produce an uppercase-only font with at least two unicodes per letter: One for itself and one for the lowercase variant (e.g. A: U+0041 & U+0061). My test results have all been positive.
Are there any known major issues?
Thanks!
Christoph
0
Comments
With multiple master, after the first master, classes and OpenType programming is worked out, I select every lowercase glyph using a select by color script, then delete. When all the masters are done, I use a script to regenerate the lowercase glyphs again. Maybe what I really need is an automatic double encoding script that I can run at the end.
I’m pretty sure this has to do with how RF calls ufo2fdk to compile.
The GlyphOrderAndAliasDB does not support multiple encodings. So you need to find a way around that, as well, for OTFs.
Yet more happy that I don't rely on any FDK-based workflow.
Further, by default makeotf will use the GlyphOrderAndAliasDB to set the unicodes in the OTF it generates, and the GOADB format does not permit of multiple encoding. So, yes, it is overwriting the cmap table.
I think this Adobe “enforcement” is a side-effect of the GOADB approach, which has other benefits, and the default behaviors.
It believe it may be possible to work around this limitation if you address makeotf directly from the command line and add appropriate flags. (I haven’t experimented yet to test by-passing the GOADB and find the right combination of flags).
Another other option would be to post-process the OTF with TTX and re-overwrite the cmap table.
0x0061 !A
If your name table isn't generating the correct unicode values, make sure that the internal name you've given to your name table isn't conflicting with something else.
BTW: From a *user's* standpoint, I strongly prefer fonts that are built this way -- the reason for this is that while many all-caps fonts use the same characters for upper- and lowercase characters, many others include variants forms for some or all letters in the lowercase positions.
As an example, consider Gudrun Hesse's Ariadne font, in which upper- and lowercase characters are identical *except* for four or five characters -- if double encoding had been used it would be much easier to tell from the glyph palette which characters actually include alternate forms.
Although I understand the reasons why some avoid double-encoding, I find that fonts which include lots of duplication of identical glyphs (e.g A.sc a.sc A.alt.sc a.alt.sc etc) end up with extremely cluttered glyph palettes.
In FL7 you have to select the .nam file in preferences, and if you want to change it you need to select a new .nam file and restart FL7.
Ideally, and I have requested this from FontLab, the .nam file should be associated with the font file, not an app preference setting at all. If I have multiple fonts open, it may be that each one follows a different naming and encoding protocol, and it makes no sense for there to be only on .nam active in the app.
Check the Unicode encoding of one of your uppercase glyphs. For multiply-encoded glyphs, you can see the codepoints either at the bottom of the Font window (with the glyph selected), or in the Glyph Panel. (The Glyph window also shows a codepoint, but only the first one, I think.)