UC-only font with double unicodes

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


Tagged:

Comments

  • We've used this fallback mechanism numerous times, and have never received complaints from our customers.
  • Chris LozosChris Lozos Posts: 1,290
    Why not just copy all of your uppercase glyphs into the lowercase slots! It is very quick.
  • Because it is less easy to maintain and requires more space.
  • Craig EliasonCraig Eliason Posts: 1,084
    That's how I produced my Ambicase fonts, and likewise haven't seen any problems. There is some potential issue brought up (in a now lost Typophile thread) about the ambiguity throwing a wrench in the computer's efforts to reconstruct an underlying text stream when processing pdf's in a certain way, but I decided for display font that was rather unlikely to come up and/or matter.
  • I just modify my composite/accent script to fill in the lc for me. I rerun the script every time I change a base glyph so it doesn’t change anything in my workflow.
  • Ray LarabieRay Larabie Posts: 1,046
    I would happily assign double Unicode for all cap fonts but those red markings in FontLab make me nervous. Wouldn't it be great if font editors could be set to all-caps mode. The lowercase glyphs would be hidden from view. Upon exporting you'd select double Unicode or components/kerning classes. About a third of my typefaces are all caps so I'd use it a lot. Currently, I do what James does.

    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.

  • James PuckettJames Puckett Posts: 1,725
    I just put components in all of the lowercase slots and Glyphs keeps everything in sync for me.
  • John HudsonJohn Hudson Posts: 2,039
    I would happily assign double Unicode for all cap fonts but those red markings in FontLab make me nervous.
    So create a .nam mapping file for all-caps fonts. The red markings indicate that the name-to-Unicode of the currently active mapping file doesn't match what you have. If you change the mapping to one in which you have double-mapped Unicodes for upper- and lowercase characters to single glyphs, the red markings will disappear. The .nam files are stored in the user/FontLab/Shared folder, and the text format is easy to figure out: it's just list of Unicode values and glyph names with a simple header.
  • I just put components in all of the lowercase slots and Glyphs keeps everything in sync for me.
    Including kerning?
  • Kent LewKent Lew Posts: 905
    For those doing their production with RoboFont, be aware that you can’t generate a font with double-encoding directly via RF’s native generation.

    I’m pretty sure this has to do with how RF calls ufo2fdk to compile.


  • Kent LewKent Lew Posts: 905
    Addendum: I believe there is also an issue with makeotf (which may be why RF doesn’t bother generating a base font with multiple mapping).

    The GlyphOrderAndAliasDB does not support multiple encodings. So you need to find a way around that, as well, for OTFs.
  • Mark SimonsonMark Simonson Posts: 1,246
    I think the same may be true for Glyphs, for the same reason.
  • John HudsonJohn Hudson Posts: 2,039
    So because Adobe need one-to-one glyph-to-Unicode mappings for Acrobat text reconstruction they made their font compiler enforce this, contrary to the cmap table specification?

    Yet more happy that I don't rely on any FDK-based workflow.
  • ufo2fdk seems to be handling UFOs multiple Unicode values per glyphs and it generates the cmap table on ots own, so it should work unless makeotf is overwriting the cmap table.
  • Kent LewKent Lew Posts: 905
    The base font that ufo2fdk compiles to hand off to makeotf does respect multiple encoding in the UFO. But, for whatever reason, the same base font from RoboFont calling ufo2fdk does not (which is inspectable if you Save FDK Parts Next To UFO in preferences). I suspect that Frederik may have subclassed the OutlineOTFCompiler and changed the makeUnicodeToGlyphMapping routine.

    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.

  • Or if you are staring with UFO sources, use ufo2ft or fontmake which do not use Adobe’s FDK.
  • Ray LarabieRay Larabie Posts: 1,046
    Anyone know a trick to get automatically double encode in FontLab Studio 5? I have a custom name table with double encodes but I doesn't work when I try generate Unicode the values get blanked out. My allcaps.nam is formatted like this:
    <div>0x0041 A</div><div>0x0061 A</div>
  • Anyone know a trick to get automatically double encode in FontLab Studio 5? I have a custom name table with double encodes but I doesn't work when I try generate Unicode the values get blanked out. My allcaps.nam is formatted like this:
    <div>0x0041 A</div><div>0x0061 A</div>
    I use this trick all the time and have never had issues, though I would strongly recommend changing the second line above to

    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.
  • Ray LarabieRay Larabie Posts: 1,046
    Thanks. All of a sudden it's working; I'm not sure why it didn't work before.
    …I would strongly recommend changing the second line above to 0x0061 !A
    What effect does that have on FontLab? Is it just good form?
  • It avoids problems if you ever use your nametable with a font which contains both A and a -- otherwise you might end up with two glyphs with the same name.
  • I haven't quite figured this out: How do I get FontLab to apply my custom nametable to a font?
  • John HudsonJohn Hudson Posts: 2,039
    In FLS5 you would use the Assign Unicode command and select a .nam file from a list in the resulting dialogue, where you could also set that .nam to be the default. I liked that system, because it made it easy to switch .nam files while working.

    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.
  • @John Hudson Thank you for clarifying that. I agree that the FL7 piece seems more confusing, and that was tripping me up.

  • So, in FL7, I've made an upper-case only .name file, and restarted. Do I then choose the "Font | Generate Unicodes" option? This doesn't seem to have any effect in the UI... I still have the lowercase glyphs as empty.
  • I think that is expected. The Font window is a showing of all the glyphs, but only one cell per glyph.

    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.)
Sign In or Register to comment.