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.

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.

Hi David,

When I export a one page Indesign document with a placed PDF image and placed JPEG image (as you suggest) the Acrobat DC preflight inventory reports the placed PDF image as:

“Color Space 1 (out of 1)
on page 1

Color Space properties:
DeviceN color space: “Black” (0.0/0.0/0.0/1.0)

Color name
Black
Alternate color space
DeviceCMYK color space”

While the JPEG image is reported as an image:

“Image 1 (out of 1)
on page 1

Image properties:
Page 1: CMYK
Width/Height (pixel): 181/482
Bits per color component: 8
Treated as a mask: False
Perform interpolation: False
Compression/encoding
JPEG compression (DCTDecode)
DeviceCMYK color space”

So while the placed PDF image is reported, the SVG for the same image was not.