Ligature support for PUA glyphs

Glyphs
1

Hello All. I am looking to add a handful (300+) ligature glyph substitutions to a font we’re working on. They will all contain glyphs from the Private User Area since there are no unicode glyphs that are usable for this purpose. I have added a ‘ccmp’ feature via Glyph’s Font Info window. The following is the definition:
script latn;
sub a uniE151 by uni0061E151;
sub a b by c;
sub a c by uni0061E151;

This exports to off fine. However, when I try to use the font, only the 2nd and 3rd substitution takes place (except in Indesign CS6). However, it is the first substitution form I need, where the glyph is in the PUA. So, is the problem the fact that the I am trying to use the glyph with unicode E151, or is something else in play, here.

The same is observed if i put the above substitutions in the ‘dlig’ feature definition, instead.

I have verified that the uniE151 character is present and that it has unicode value E151.

Many Thanks for your thoughts,
– Steve.

2

The substitutions can be put together automatically by Glyphs if you name them a_uniE151.

As for the feature not working outside InDesign, how and where do you test the font? Are you aware of this:
http://glyphsapp.com/blog/eliminating-font-cache-problems/

1 Like
3

Thanks for the info. I did not know about the magic steps to refresh the font cache – excellent info to have!

I usually test the font in TextEdit and Word Mac since the target is ultimately to have the font function according to plan with MS Word on the Mac, and perhaps Windows. They are installed via Font Book because I know in the end it will have to pass Font Book’s validation process for the end users (a handful of people who need this sort of thing) to be comfortable with it.

In anycase, I tried it in TextEdit and Word, as well as Indesign CS6 and Mellel. The proper substitution takes place in Indesign and Mellel but does not occur in TextEdit and Word. I have selected All in the Word where one determines which Ligature ‘class’ to activate so it ‘Should’ work. But…

I have never run into anything in the documents that say the GSUB can’t function properly if one of the target glyphs are in the PUA, but I’m just a novice at this stuff. So maybe it’s something with the glyph itself? Does it matter if it’s identified as a marking character or simple or … ? I’ll look to see if there’s anything with it that stands out. Sigh… Getting closer, though.

Thanks,
– Steve.

4

I bet it is a cache problem. Rename your font every time you export, as described in the blogpost.

What do you need the PUA for anyway?

5

I tried refreshing the cache via the Applescript you pointed me to but it doesn’t change the behavior that I’m observing. Since I didn’t actually create the glyphs I don’t know if there is something funny with those particular glyphs. However, I did make a simple oval glyph and put it into the PUA and, again, it works in Mellel and Indesign, but not MS Word.

The project is for my Sister who works with a college translating ancient sanskrit texts. What she is working on originate in the pre-written age so everything was part of the oral tradition. As such, she needs to capture (as I understand it) the ‘singsong’ characteristics where the pitch or tenor might change which would then alter the underlying meaning.

The attempt is to rely on OpenTypes ligature-type substitutions to simplify the keying in of these glyphs since she is creating the keyboard layout to match this font. The hope was the user could type the letter ‘a’ and then the glyph with unicode E151 (which is a ‘1’ in the same location as a macron might be) and have the substitution occur. However, in writing this I realize that there is no need to have the E151 glyph as we could use anything for the second character since it would not be seen since it is always substituted out. So we would just need to use glyphs that would ‘never’ be juxtaposed.

I just tried this and it works if I use
sub a uni0279 by uni0061E151;

It makes the correct substitution in MSWord as we would like (oddly, it makes the substitution even if Ligatures is turned off). This is a reasonable work around, I believe. Not ideal, but suitable for a first go-'round. The question, however, remains: Is there something about the glyph residing in the PUA that makes the OpenType substitution fail? I can find nothing saying this is so, but this is all pretty new territory for me.

Many thanks for your continued support!
– Steve.

Just as an after-thought, I modified the Arial font, added a PUA glyph and tried the substitution in there, to no avail. It is beginning to seem like a GSUB/PUA issue, though I can’t imagine why…

6

The OpenType support in Word is quite new and might not work as expected.

You might ask the question on typophile.com There are people there that should know something about it.

7

Hi George. I guess I’m not entirely surprised that MSWord is having a difficulty with it, but I find it rather peculiar that TextEdit is having problems (Pages, too). Anyway, I did put a msg. up on Typophile and nothing definitive has come back yet. In the meantime, we have a work around and will be able to go forward with this until things get straightened out with PUA integration.

8

What I still do not understand is why you would use the Latin a for a Sanskrit substitution. This should be solved in the keyboard layout.

9

From a linguistic standpoint, I can’t really say why they would be doing this. Suffice it to say, though, that the unicode standard does not fulfill their need at this point otherwise they would be using what was available. I believe they have been party to several proposals to the standards committee but for now they’ve got to rely on their own efforts. Maybe someday things will change, but that is usually slow coming.