I'm an end user of type rather than a designer, but having said that, we do augment our fonts whenever the EULA - or special permission -- allows. So, I do have some experience with moving characters (and usually move the ornaments), adding characters, and writing simple features.

So here is my thinking: If you are switching on ornaments using either stylistic sets or the ornament features, there is no need to make the substitutions complicated. One to one works just fine. The user has already had to take an action to "turn them on," and should be well aware that the characters keyed -- or in the file -- will not be what appear.

Having said that, we prefer to have the ornaments coded, in the Private Use area. As you say, any later use of the text now has a flag that the characters so encoded need attention. Moreover, they are accessible from programs that support Unicode but do not support some OT features.

YMMV

Thanks for your input.

If I read you correctly, you're advocating opentype substitution a → orn.1, provided orn.1 has a PUA encoding? Is that what you meant?

I did a little test on this in InDesign CS2:

Access method one: opentype substitution a → orn.1, with and without PUA on the orn
When switching to a different font it reverts, orn.1 → a. I had hoped the PUA encoding would prevent the return.

Access method two: glyph palette hunt and peck
When switching to a different font it highlights in red, regardless of PUA encoding. This is the preferred result.

- - -

So PUA doesn't help in the way I'd hoped it would, but perhaps it's still worthwhile so that the illustrations are accessible in unicode apps without a glyph palette (not sure what that might be? Photoshop?). Here is what I'm currently thinking: use opentype sub for the banners (ornm & stylistic set) because that will make user's life much easier. For the illustrations, leave them unencoded and unfeatured with access via glyph palette. Yes this means a font switch will result in 4===4 showing up, but banners require attention to compose, are often converted to outlines/rasterized, and are rare -- so I don't think it's too much of an issue.

This seems like it might suit the pragmatists amongst us, but I'm curious what the by-the-spec crowd thinks?

To be clear, what I'm advocating is using the PUA encoding without using any Opentype feature to switch a character with an ornament. That way, if you shift to a font that lacks the ornament -- actually, lacks a glyph with the same PUA number -- you get nothing but "salmon," which is as it should be.

You can access PUA characters from the glyph pallet of course, but you can enter the Unicode number directly in InDesign. Or MS Word or EditPad Pro, for that matter. Dunno about Quark, but likely.

Using an OT feature as you describe has all the minuses you've noted, with, I suppose, a plus that people who don't know how to enter a Unicode character directly in ID have a crutch.

Come to that, I also dunno about a Mac. To enter a Unicode number with Windows (make sure NumLock is on), hold down "alt" key, hit "+" on the keypad, followed by the numbers (also using the keypad), with any alpha caps from the regular keyboard. Then let go of the alt key. Takes longer to describe than to do. Probably something similar with the Mac.

In either case, a *readme* with the font would be nice. I always made a readme listing all the features, and any other special functions/features, and I only have to please two other comps. And of course myself, the next time I go back into the font, muttering "what the hell did I do . . .

Thanks. I've been known to mutter myself :-)

I'm with Charles on this one. Pretty strongly so. If it's not a variant of a real character, it should not be an alternate of that character through an OpenType feature.

If I could deprecate one more feature from the OpenType spec, I'd do that to 'ornm' and put it in the same purgatory as 'crcy' and 'dpng'.

Cheers,

T

Just a thought. If ornm is used to 'link' ornaments to, say, the glyph encoded as bullet, then this feature has a useful function: to categorize otherwise unencoded ornaments as ornaments and allow applications to present them in 'controlled' manner (rather than exposing any glyph in a glyph palette). This of course requires that applications treat OT layout tables, if present, as kind of a cmap extension rather than mere gimmickry.

Karsten: That's the most reasonable implementation of 'ornm', if one is to do it at all... but it doesn't work well with non-OT-savvy representations of text. It relies on choose-one-of-many-alternates abilities that are lacking in too many places, and may continue to be lacking for another 5-10 years in some places, or even indefinitely in others.

I think your option is every bit as theoretically valid as using PUA codepoints, but less useful in the real world. I came to this conclusion in large part from looking at real-world workflows and talking to engineers working on applications.

Regards,

T

I think your option is every bit as theoretically valid as using PUA codepoints, but less useful in the real world.

I am fully aware of this.
As to the real world, it may be time to change the way we evaluate applications. Rather than regarding those that support OT as plus and those that don't as standard, we should regard OT-savvy ones as standard and all others as defective. It is a matter of awareness.