Custom glyph names in the Private Use Area

Mans's picture

Hi all,

I tried asking this question over at the FontLab forum, but there doesn’t seem to be very much activity there, so I’m trying here as well. Apologies in advance if this question has been asked before – at any rate I have not been able to find an answer in the archives.

I am developing a font which includes a large number of glyphs in the Private Use Area. For these I would like to use my own names, primarily because many of them have alternate forms accessible through aalt, stylistic sets etc. Coding would get much easier if I could use semantic names rather than “uniExxx”, especially in case I want to change the Unicode index of a glyph (each time I do that, I have to track down every reference to that glyph in the code and change the name).

Problem is, when I use my custom names the OpenType features stop working, and InDesign gives the glyph names as <null>.

Is there any way to get custom names to work? If this has been answered before, kindly point me in the right direction. I read somewhere a comment to the effect that “sometimes it works, sometimes it doesn’t, but I don’t know why”.

Oh, and I know custom characters should not always be in the PUA. Suffice to say, I want them there in this particular font.

Yours,

Måns

agisaak's picture

Coding would get much easier if I could use semantic names rather than “uniExxx”, especially in case I want to change the Unicode index of a glyph (each time I do that, I have to track down every reference to that glyph in the code and change the name).

When you change the name of any glyph in fontlab you're given the option of changing the name in all code and classes as well (there's two checkboxes in the glyph names dialogue that you'll need to check).

Your choice of names should have no bearing on how your opentype features work (compiled features refer to GIDs alone, not unicode values or glyph names) so I suspect whatever is causing your features to not work properly is a separate matter.

I'd use whatever names you want while developing the font and then change them to follow the proper naming format once the font is completed.

André

agisaak's picture

Also, the glyph names are normal. The InDesign glyph palette doesn't get its names from your font. It looks them up based on unicode value, and there are no standard unicode names for PUA code points.

Mans's picture


When you change the name of any glyph in fontlab you're given the option of changing the name in all code and classes as well (there's two checkboxes in the glyph names dialogue that you'll need to check).

Thanks! Yes, I noticed that little handy feature. That's one problem less. Unfortunately it's not the main problem.


Your choice of names should have no bearing on how your opentype features work (compiled features refer to GIDs alone, not unicode values or glyph names) so I suspect whatever is causing your features to not work properly is a separate matter.

And yet when I change the name, aalt substitution stops working. When I change it back it starts working again. (And it is not because the name is not changed in the code; the font compiles with no errors.)


I'd use whatever names you want while developing the font and then change them to follow the proper naming format once the font is completed.

Yes, that was my plan. Good to hear that I'm not the only one doing it that way.


Also, the glyph names are normal. The InDesign glyph palette doesn't get its names from your font. It looks them up based on unicode value, and there are no standard unicode names for PUA code points.

Not true. The InDesign palette (in CS3) gives the PUA glyphs name along the line of "<private use area-Exxx>", except my renamed glyphs which are named "NULL".

agisaak's picture

Sorry, my mistake. I know I frequently get for glyph alternates which are the *results* of GSUB rules, but it sounds like you are talking about base glyphs.

André

twardoch's picture

Glyphnames for alternates are better to be "meaningful" even if you encode them in the PUA. So "A.ss01" is better than "uniE012".

Mans's picture


Glyphnames for alternates are better to be "meaningful" even if you encode them in the PUA. So "A.ss01" is better than "uniE012".

My thoughts exactly. So, any insights on how to make OpenType features work with meaningful names in the PUA? Or am I the only one who has this problem?

/Måns

Mans's picture

Adam, I was reading sloppily the first time I saw your post. Reading it again I understand what you mean. What I have done is generally to not give Unicode numbers to alternates, just the original glyph. My current scheme is to have glyphs with names like "uniE000" (and Unicode index E000), and alternates with names like "uniE000.alt1" (no Unicode index).

For obvious reasons I would rather like to use names like "meaningful" and "meaningful.alt1" (but with preserved index for the "meaningful" glyph). Unfortunately, this is where the problems start. Any idea why?

/Måns

twardoch's picture

Mans,

"uniE000" or "uniE000.ANYTHING" will map back to U+E000.
"anything" or "anything.ANYTHING" will map back to an unknown glyph.

So if you employ your own encoding scheme (say, for a private language), you typeset some text in a text editor, produce a PDF, copy the text from PDF and paste it again into the text editor, you will get the same text (without alternates or formatting, but at least the text) if you use the glyphnames "uniE000" or "uniE000.ANYTHING", but you MAY get a string of undefined characters if you use the glyphnames "anything" or "anything.ANYTHING".

The reason why I wrote "MAY" rather than "will" is explained in detail in this thread:
http://typophile.com/node/29469#comment-404691
(PDF-compatible glyphnames is the magic term).

Adam

agisaak's picture

My thoughts exactly. So, any insights on how to make OpenType features work with meaningful names in the PUA? Or am I the only one who has this problem?

As I said earlier, I don't think that the problem you are having with your code not working is related to the naming issue here -- or at least I've never run into a problem where particular glyph names prevent features from working. I think this is probably a separate issue. If your (non-working) code is relatively small, you might want to post it here.

André

Mans's picture

Adam, thanks for the link to that thread, it explained a lot!

André, after a lot of experimenting I can conclude that you were right. For some reason, FontLab decided to discard the Unicode index from my renamed glyph each time I exported an OpenType font, and instead insert the "space" glyph (of all things) in that position. (Probably some other problems arose behind the curtain, since the OpenType features stopped working at the same time.) I solved the problem by right-clicking on the glyph and selecting "More>Remove Unicode", then reapplying the Unicode index to the glyph that was meant to have it.

Thanks to you both for all support and suggestions.

Måns

andi aw masry's picture

Greeting to you all.

Related my question in this thread http://typophile.com/node/29469#comment-470244 .... I wrote again here because there are similarly topic:

I understand haphazardly regarding adobe glyphs as follows:

  1. That all the glyphs should be mapped back into the map table and encoding based AGL AGLFN last ver for OT fonts today.
  2. PDF is a sort of "catalyst" to determine the quality of an OT font, so the naming and coding of glyphs absolutely must meet the standards on above (number 1).
  3. Glyphs which included into the range as wide as any, remain to be defined into unicode which will only lead to - at least - 31 characters. Related to the Adam's explanation. Is it true to be defined—example—the "B" name glyphs into cmap table like this:
    0x0042 !B.alt1
    0x0042 !B.alt2
    0x0042 !B.alt3
    0x0042 !B.medi1
    0x0042 !B.medi2
    0x0042 !B.ss01
    0x0042 !B.ss02
    0x0042 B

Will they be defined precisely? Whether this is meant by Adobe? ... Note that in this way will not display alternate glyphs on the Quick Test FL (and I suspect also in generating fonts). Glyphs to be shown is that explicitly have a unicode, including characters that have PUA code. Please enlightenment.

Best Regards.

twardoch's picture

Andi,

no, this portion of .nam will cause that A.ss01 will get the Unicode U+0041 if you do "Generate Unicode", and A will also get that Unicode, and you'll get conflicts. In a font, only one glyph should exist out of those which have the same Unicode in a .nam file. Basically, what you're showing is that if your font has A.ss01 and no A, and you'll do "Generate Unicode" and then "Generate Names", then your A.ss01 will be renamed to A. Which I don't think is what you want.

Do not put any glyphs that should be accessed through OpenType Layout features into the .nam file. The .nam file specifies glyphnames that should have Unicodes, and glyphs that have Unicodes are accessible directly through the "cmap" table, without OpenType Layout.

All glyphs that are accessible though OpenType Layout features should only be specified in the OpenType Layout feature definitions (OpenType panel and perhaps Classes panel).

Best,
Adam

twardoch's picture

Ps. You MAY add PUA codepoints into your non-Unicode glyphs, i.e. you could do:

0xE005 !B.alt1
0xE006 !B.alt2
0xE007 !B.alt3
0xE008 !B.medi1
0xE009 !B.medi2
0xE00A !B.ss01
0xE00B !B.ss02
0x0042 B

Or something like that (the PUA codes you assign are arbitrary, I've just chosen some -- but you're really free to occupy the space between 0xE000—0xF8FF). If that's what you really want. Of course, you'll still need to write OpenType Layout features, but you'll get an additional access method to those glyphs, through "cmap", using PUA codepoints. This access method is not recommended, but if you want those glyphs to be accessible in application that do not support user-controlled OpenType Layout features, this may be a sensible scenario for you.

Best,
Adam

andi aw masry's picture

Thanks Adam, I can learn quickly to this. You also have to explain things in a separate thread. :-)

Best

Syndicate content Syndicate content