Non-ASCII font names — pros and cons

Adam Jagosz
Adam Jagosz Posts: 689
in Font Technology
Occasionally you can find fonts drawing attention by a diacritic in the name, like Jazmín or Byŏm.
While I can see some benefits in this, like promotional boost, the quality of being edgy, there are some obstacles (FontLab and FontForge are not 100% compatible with generating fonts with such names, so you might end up tinkering with the name tables manually). Can you point any other drawbacks, like user confusion, or OS/app incompatibility or difficulty finding the font by typing etc.?
I don't know if the examples I mentioned actually go all the way with the accent accent, or perhaps just in the branding. Maybe the actual font files have the accent stripped to prevent any problems? But wouldn’t promoting one name and using another actually cause more problems?
Tagged:

Comments

  • Thomas Phinney
    Thomas Phinney Posts: 2,883
    There are several places to think about:

    - Internal things that are rarely exposed to users, notably the PostScript font name. The PS font name MUST use ASCII only, no diacritics. You can use the proper name in things like copyright and trademark notices and other long text fields, however.

    - the file name. I would be inclined to stick to ASCII. I don't think this would be a problem to users, though you might disagree.

    - the various kinds of menu names. This is what users normally see. Using diacritics here may break compatibility with some ancient operating systems and/or apps. The nature of this breakage will likely vary. The real question is ... just how old and which ones? My knowledge here is pretty thoroughly out of date. It would be helpful to get feedback from folks using this recently.

    Adobe has one of these fonts, btw. Orgánica by Gabriel Martinez Meave.
  • Adam Jagosz
    Adam Jagosz Posts: 689
    edited December 2019
    What I'm exactly curious about is whether the other name fields in these fonts as well as filename follow the PS font name (name id 6) or the proper accented name. The former would be the way to “play it safe” and the latter is, I guess, the more risky path.
    FontLab is actually not ready for such hurdles in that it garbles the PS name when the main name has accents: it cuts the diacritics out instead of replacing them with ASCII characters (I believe an ideal solution would be to provide a separate “romanized name” field).
  • Thomas Phinney
    Thomas Phinney Posts: 2,883
    edited December 2019
    Which "other name fields" in particular?

    I hope you have reported the FontLab bug you mention—that ought to be fixed. Although of course you can set the PS name manually, so this is not a large hurdle for a user to work around. (I left FontLab six months ago, so not my thing any more.)
  • Adam Jagosz
    Adam Jagosz Posts: 689
    > I hope you have reported the FontLab bug you mention
    I sure did. Over several months, I reported several dozens bugs. Since May 18, I filed 244 tickets. Should I consider applying for employment?
    > Which "other name fields" in particular?
    Name ID 1, 4, 16, possibly 3.
  • Yury Yarmola
    Yury Yarmola Posts: 23
    … it garbles the PS name when the main name has accents: it cuts the diacritics out instead of replacing them with ASCII characters

    I believe it has been fixed in some later FL7 build.

    My understanding is that you may use non-ASCII characters in your font names (except PS Name), but in case of Macintosh platform you probably will be limited to characters in the MacOS Roman codepage.

    Of course, [name] table structure allows to specify many alternative names for different languages, but current UX support for that in FontLab is very limited.

Categories