UC-only font with double unicodes

Christoph Koeberlin
Christoph Koeberlin Posts: 51
in Technique and Theory
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

  • Erwin Denissen
    Erwin Denissen Posts: 300
    We've used this fallback mechanism numerous times, and have never received complaints from our customers.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Why not just copy all of your uppercase glyphs into the lowercase slots! It is very quick.
  • Erwin Denissen
    Erwin Denissen Posts: 300
    Because it is less easy to maintain and requires more space.
  • Craig Eliason
    Craig Eliason Posts: 1,436
    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.
  • James Hultquist-Todd
    James Hultquist-Todd Posts: 417
    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 Larabie
    Ray Larabie Posts: 1,431
    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 Puckett
    James Puckett Posts: 1,992
    I just put components in all of the lowercase slots and Glyphs keeps everything in sync for me.
  • John Hudson
    John Hudson Posts: 3,186
    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.
  • Paul van der Laan
    Paul van der Laan Posts: 242
    James Puckett said:
    I just put components in all of the lowercase slots and Glyphs keeps everything in sync for me.
    Including kerning?
  • Kent Lew
    Kent Lew Posts: 937
    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 Lew
    Kent Lew Posts: 937
    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 Simonson
    Mark Simonson Posts: 1,734
    I think the same may be true for Glyphs, for the same reason.
  • John Hudson
    John Hudson Posts: 3,186
    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.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    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 Lew
    Kent Lew Posts: 937
    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.

  • Khaled Hosny
    Khaled Hosny Posts: 289
    Or if you are staring with UFO sources, use ufo2ft or fontmake which do not use Adobe’s FDK.
  • Ray Larabie
    Ray Larabie Posts: 1,431
    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>
  • André G. Isaak
    André G. Isaak Posts: 632
    Ray Larabie said:
    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 Larabie
    Ray Larabie Posts: 1,431
    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?
  • André G. Isaak
    André G. Isaak Posts: 632
    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.
  • Brian Hanechak
    Brian Hanechak Posts: 3
    I haven't quite figured this out: How do I get FontLab to apply my custom nametable to a font?
  • John Hudson
    John Hudson Posts: 3,186
    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.
  • Brian Hanechak
    Brian Hanechak Posts: 3
    @John Hudson Thank you for clarifying that. I agree that the FL7 piece seems more confusing, and that was tripping me up.

  • Brian Hanechak
    Brian Hanechak Posts: 3
    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.
  • Thomas Phinney
    Thomas Phinney Posts: 2,883
    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.)

Categories