CreativePro Forum

Return to Member Forum

• Author
  Posts
• • May 23, 2020 at 1:58 pm #1251912
    Fran O’Reilly

    Member

    Hi,

    I would like to know if any users of the IndyFont script for creating custom fonts from within InDesign have encountered problems getting their custom font glyphs correctly printed by a commercial printer. I expect you would package your custom fonts using the InDesign File > Package . . . command and send the created folder on to the commercial printer.

    Thanks.

  • May 23, 2020 at 2:43 pm #1251923
    David Blatner

    Keymaster

    I haven’t made an IndyFont in a while, but when I did, I had no trouble with it, and have never heard of anyone having problems with them. It’s pretty amazing. Yes, they’re fonts like any others, so you can package them.

  • May 23, 2020 at 5:31 pm #1251933
    Fran O’Reilly

    Member

    Thanks David.

    Both the examples you give at https://indesignsecrets.com/creating-a-custom-bullet-or-character-with-indyfont.php and Mike Rankin gives in his InLeaning font management course (see: https://www.indiscripts.com/post/2014/01/getting-started-with-indyfont-pro) are bullets.
    A bullet has a specified Unicode code point (U+2022). And most InDesign users will be creating custom letters, eg a fancy capital A (U+0041), which also have specified code points.

    However, my particular interest is in a case the IndyFont manual discusses:

    “What of characters that do not have a Unicode? You may want to draw a character-plus-accent for which there is no code (yet) . . . or you added a custom ligature, or perhaps you want to have a single character in the shape of your company logo. Unicode even allows for this: the code range between U+E000 and U+F8FF is designated as “Private Range”, and you can put anything you like under one of these available 6,400 “free” codes.”

    Now the Unicode Core Specification Version 6.1 (Allen et al, eds) states (most importantly the final clause):

    “Private Use – Three ranges of code points have been set aside for private use. Characters in
    these areas will never be defined by the Unicode Standard. These code points can be freely
    used for characters of any purpose, but successful interchange requires an agreement
    between sender and receiver on their interpretation.”

    So, two sender-receiver relationships arise: IndyFont and InDesign; and, later, InDesign and, say, platemaking software in a commercial printer. If “agreement” does not occur, either by how the unicode specs are implemented or fortuitously, your custom glyphs will get replaced by an empty rectangle.

    I wonder are any users of the IndyFont script aware of this happening? Or, have people who have used characters with no Unicode code point in custom fonts made with other apps encountered this problem.

  • May 24, 2020 at 7:59 am #1251943
    David Blatner

    Keymaster

    Hi Fran, I don’t think there is a problem here. When the IndyFont manual talks about glyphs for which there is no Unicode code, they mean glyphs that are not officially recognized by name in the Unicode standard. But these glyphs will still have a unicode number… that is, they will still have an encoding value so that InDesign knows where to find the character inside the font.

    For example, you can draw any shape you want and stick it in a private use area, like at Unicode U+100F00. So it has an encoding (a number), and InDesign can use it.

    The only time you’d have a missing glyph error (empty rectangle) is if the font is not available.

    Also, if you export to PDF and give the PDF to the printer, then you particularly don’t have to worry about it, because the font is embedded inside the PDF.

  • May 24, 2020 at 3:13 pm #1251953
    Fran O’Reilly

    Member

    Clearly what you say, David, is true for most users.

    But these quotations (with me using capitals for emphasis) from Unicode Core Specification Version 6.1 (Allen et al, eds):

    “Interpretable but Unrenderable Characters – An implementation may receive a code point that is assigned to a character in the Unicode character encoding, but be unable to render it because it lacks a font for the code point OR is otherwise incapable of rendering it appropriately.”

    “Fallback Rendering – Fallback rendering occurs when a text process needs to display a character
    or sequence of characters, but lacks the rendering resources to display that character
    correctly. The TYPICAL situation results from having text to display without an appropriate
    font covering the repertoire of characters used in that text.”

    show its authors are apprised of untypical situations that can cause software to be incapable of rendering a character.

    I’m wondering how commonly such situations are encountered to assess if there is a pitfall one needs to consider.

  • May 25, 2020 at 5:22 am #1251963
    Fran O’Reilly

    Member

    There’s a couple of other points I might usefully add

    Unicode is essentially about trying to ensure computers can simulate human language use. So U+0041, what we know as a capital A, has a long list of properties supposed to describe how it functions in the languages in which it’s used. A corporation like Adobe is totally committed to the project of developing computers that can pass language competence tests. So it’s likely to take very seriously what the correct properties of U+0041 are. Hanging a Party Hat glyph on an A which has nothing to do with how A functions in languages, as custom font creation apps allow, is a bad practice and will likely run into problems down the line.

    But then you have to assign your custom glyph to a private use Unicode code point. The feudal situation with respect to these code points which the wikipedia page David links to (https://en.wikipedia.org/wiki/Private_Use_Areas) seems to describe would not inspire confidence in me.

    My feeling is there is not enough emphasis on commercial printing considerations generally. It seems to me that the best real world test for a professional designer is whether you can reproduce your wonderful design as ink on paper. If, even with the best intentions, you have to rely on an element of chance, then there is something wrong with the design-to-print system.

  • May 25, 2020 at 5:57 am #1251973
    David Blatner

    Keymaster

    Fran, I don’t know what the “element of chance” is that you refer to. Nothing you have said seems to indicate any problem with using properly built OpenType fonts.

    You opened the discussion asking if anyone has had any trouble with fonts created with IndyFont, and no one has said yes.

    I’m not sure what your concern is, or what you are arguing.

    Have you tried IndyFont? If not, why don’t you try it? It’s free for making a single glyph. Make some fonts and test them yourself.

    Or, use a different font tool.

• Author
  Posts