Where to place special characters in a font

DanielilloDanielillo Posts: 10
edited January 19 in Technique and Theory
I am designing a font with some special characters like different types of arrows. I know that I could use any free space in a font map to place them but I would like to know which characters are the most suitable to place them so they are:
  • Easy to find for a future user
  • Easily accessible on the keyboard
I'm working with FontLab and for the base design, I'm temporarily using MacOS Roman character set.

Comments

  • John HudsonJohn Hudson Posts: 2,347
    edited January 19
    What Andreas said.

    Here are search results for arrows in Unicode:
    https://www.fileformat.info/info/unicode/char/search.htm?q=ARROW&preview=entity

    Note that those results include all the arrow characters in Unicode including those used as symbols or combining marks in phonetic transcription systems and other forms of semantic text. You will need to look through the results to find the ones that make sense to map to your glyphs.

    Also take a look at the Unicode glyph charts specific to arrows:
    Arrows
    Supplemental Arrows–A
    Supplemental Arrows–B
    Supplemental Arrows–C
    Miscellaneous Symbols and Arrows


  • If you don’t find your glyphs as characters in the UCS, there are two possibilities to still incorporate them:
    a) make them variant glyphs of standard characters and make them accessible via OT functions;
    b) put them somewhere in the so called Private Use Area.
    Neither of those options is ideal, however.
    The one advantage of doing the latter is that if the font is unavailable special characters in a document are more likely to show up as .notdef boxes than as random letters or numbers which might be misidentified as typos.
  • Using

    $ uni search ARROW | wc -l

    there are 618 characters found with ARROW in the name. 174 of them are Math_Symbols.

    I wouldn't expect that the current assertions in Unicode are not enough. But there are still some symbols (alchemy, pharmacy, botany) which are used in printed books but don't have a Unicode code point.

    Technically a glyph does not need a codepoint in a font. Using the PUA is a last resort and problematic in many ways. But if the PUA is used, why not also support them via OT functions. You can support both.

    But in any case don't misuse other codepoints for keyboard convenience. E.g. asserting long_s to $, or mapping Hebrew glyphs to ASCII letters (such fonts still exist), as this did a lot of harm and destroyed data. As a font designer you should care about input methods. There are still many possibilities to input special characters like HTML sequences, special escape sequences like TEX does, virtual keyboards, character pickers etc.

  • John SavardJohn Savard Posts: 962
    As for your honorable intentions:
        • Easy to find for a future user
        • Easily accessible on the keyboard …
                … I have only bad news for you. It just ain’t going to happen because it is not possible. The conventional keyboard is the one great obstacle which safely prevents users from accessing anything but the 19th century typewriter basics, as sad as it is. Everything beyond that will force you and your audience to pass the iced bridge towards the door opening to sinister arts and dark science.

    Now, that's not quite true.
    There are plenty of "dingbat fonts" in the .ttf format for Microsoft Windows that were developed for use under Windows 3.1, which did not have Unicode support. So they just assigned the special characters... to the code positions of "the 19th century typewriter basics"... plus the additional characters added in the 1970s for ASCII terminals with lower-case.
    That may be a currently deprecated option, but it exists.
  • John Savard said:
    There are plenty of "dingbat fonts" in the .ttf format for Microsoft Windows that were developed for use under Windows 3.1, which did not have Unicode support. So they just assigned the special characters... to the code positions of "the 19th century typewriter basics"... plus the additional characters added in the 1970s for ASCII terminals with lower-case.
    That may be a currently deprecated option, but it exists.
    Could you make clear what is your point here?
    Are you suggesting that some 1970ies hack is to be regarded as a solution for current character encoding and access issues?
    Everyone is free to do whatever hack which comes to his mind, of course. But to speak of solutions is another matter, i.m.h.o.
  • Nick ShinnNick Shinn Posts: 1,846
    edited January 21
    The good news:
    In any application with a “glyphs” palette (nothing to do with the font editor), a group of arrows will be easy for users to find.
    Characters such as the primes are much harder to locate!

    In FontLab, go to Index mode and move the arrows to the end of the window (if not already there), to make them especially obvious in glyphs palettes.
  • I wouldn't quite say that fonts like the Symbol font included in Windows are hacks. The TrueType and OpenType specs allow for a 'cmap' table to include a subtable for the "Windows symbol" encoding, which is distinct. It's basically comparable to Unicode PUA, but it's not Unicode. Fonts that use a Windows symbol 'cmap' are following industry specifications so, in that sense, aren't hacks.

    Now, those font-format specs don't specify what numeric character codes should be used, and they don't clarify how text using those fonts should be represented in documents. So, that's a bit of a hacky "wild west".
  • John SavardJohn Savard Posts: 962
    Could you make clear what is your point here?

    Merely to note that what is not recommended, what is not considered advisable, is not at all the same as what "is not possible". I realize you may feel that good practise should be what is shown to beginners, but one should still be accurate.
    Of course, one important caveat must be noted: back in the days of Windows 3.1, a font with characters that were miscoded was at least an effective way of putting special characters on paper with your laser printer. Of course, it still is.
    But such a font does not work for putting special characters on a web site, because a user may elect to view the web site with default fonts - and so for Internet use, Unicode-conforming fonts are indeed a practical necessity.
Sign In or Register to comment.