How PDF handles PUA glyphs

1

First of all this question is not related to Glyphs app. More about how Adobe handles Private Use Area glyphs.
Here is a screenshot showing how things are:

There are three letters: b and two of it’s alternates each of them has unicode value assigned. Everything looks fine in pdf.
BUT if I want to copy/paste from the pdf, Adobe Illustrator doesn’t recognize the two alternates.
Does anybody knows if there is a way to fix this? Perhaps some settings in either Illustrator or Acrobat?

What I’m trying to achieve is, for a font that has a lot of alternates, have all the glyphs listed in a file so users can copy/paste from the pdf into a document instead of surfing the PUA table looking for the alternate glyph they need. Surfing might be not that bad but if the font is layered and not all layers are easily recognizable (lets say it’s a shadow or a kind of letterpress effect fill…) - this can be a nightmare…

2

This is not what Unicode is for. Unicode is a character encoding, not a glyph encoding.

Do not assign PUA codes to glyph alternates, unless the alternates mean something else besides lowercase b’s, which I believe is not the case here.

3

I agree, it’s definitely what Unicode is for, but, shouldn’t PUA characters be copy-pastable, whatever their glyph forms happen to be? I can’t see why this wouldn’t actually work. Are the Adobe apps constrained to look at GID perhaps?

4

You will have to have a matching glyph name (uniXXXX scheme).

1 Like
5

@elena Give that a try, give them production names as uniE78C, uniE812, it might work.

6

@mekkablue @Bendy, thank you guys!
I will give it a try.
The thing is I need this to work the usual “ss0X” way in open type aware apps. Do I just need to modify the ss0X functions replacing A.ss0X with uniXXXX in order this to work?

7

I do realise that this is probably abusing Unicode :slight_smile: But I can’t find another way to make all glyphs accessible within non OpenType aware apps. :worried:

8

Yes, the feature will no longer get written automatically so that’s exactly what you’ll need to do. But try it with a couple of glyphs first, before rewriting your whole code, in case it doesn’t work.

9

Thanks, Ben, will do exactly that.
… it would be a major failure to do the whole thing and to find out it doesn’t work :joy:

10

@mekkablue @Bendy - just to let you know - it doesn’t work :sweat:
Removing the ss0x functions didn’t help either

11

Glyphs you can set the production name manually. That way you get proper PFD handling and automatic feature code.

12

Oh. Are you certain the glyph names in the exported font are in uniXXXX format? (In Glyphs this is the ‘production name’ field.)

13

@Bendy - where can I see that?

14

In the source file, click cmd-alt-i on one of the relevant glyphs in the main tab to see ‘info for selection’ and check the ‘production name’ field. Or open one of the exported OTFs in Glyphs and check glyph names for those ones.

15

@GeorgSeifert - Any tips how to do that, George? Any tips? Please? :innocent:

16

@Bendy - the production name is correct but the box is not ticked. Is it the reason?

17

No, I think that just means it’s using the correct production name by default, and it hasn’t been user-edited.

18

Another funny thing.
When a character was named A.ss01 (with unicode E000 assigned) - the glyph was showing up in PopChar and I could copy/paste it into a Word document. When I renamed the glyphs to uniE000 - the glyph is not visible in PopChar (it says there is 1 character in Private Use Area though) and it is not copy/paste-able

19

Sorry guys, I’m still trying to understand why this doesn’t work with pdfs…
@GeorgSeifert - did you mean that I can keep the names of the glyphs as is (A.ss01 etc) - so the features can still be generated automatically - and by using set.productionGlyphName assign uniEXXX names to all the glyphs that has no unicode and this should work well with pdf?

20

Elena, you are trying a hack here. You try to use PUA for something it is not meant for. Even if you get the one workflow to work for the current version of a certain PDF viewer (and there is no guarantee the PDF viewer will let you circumvent the character stream), there is no guarantee it will work in the future, or with another version, or another PDF viewer.

And even if it works, you are breaking your character stream with it. That means your text would not be searchable, copy-pasteable, transferable anymore. You have mentioned problems in PopChar already. Are you really sure you want to do that, just to find a workaround for apps that do not support OT properly?