Ordinal »i« and InDesign 7.0.4

yanone

Hi everyone,
I’m having trouble with the ordn-Feature and the superior »i«.
My InDesign 7.0.4 doesn’t replace it, whereas all the other ordinal letters work fine.
It also works as expected in Illustrator and earlier versions of InDesign.



The responsible OT code is this, and I double checked that the i is included in source and target @ordn classes.
sub [@ordn_numbers @ordn_target] @ordn_source' by @ordn_target;

Does anybody else have this problem, maybe in newer version of InDesign? If not, I shall ignore this bug, since it must be specific only to this InDesign version.

Thank you.

Thomas Phinney

Actually, InDesign IS replacing it—with nothing. That is much more surprising than some other possible kinds of failure.

I would be curious to look more closely at the font, classes and code, because it is such a weird failure. If you feel like sending me a VFB (or other source) I would be happy to take a look at it.

Kent Lew

Thomas, I think you might have misunderstood Yanone’s example (or else I did).

What I think I’m seeing is: in the first example, ème are correctly superscripted; but in the second example, as soon as an i is introduced at the head of the string, the entire substitution is broken and none of the string is superscripted.

I wonder whether there is perhaps another GSUB lookup with the same target and backtrack sequence that is somehow intercepting that particular {ordn} rule in this case. It’s a long shot, but that would explain the behavior. Although, in that case, I would expect the behavior to carry over to other apps – unless the intercepting lookup is in a feature unsupported in the other apps. (Just thinking out loud here.)

yanone

Kent is right with his assumption, that the composition breaks as soon as the i is being introduced to the string. I should have explained more clearly.
I accepted Thomas’s offer to take a look. Curious to hear what he says. Thanks, Thomas.

Thomas Phinney

Hi Yanone,

So I was spelunking your font, and I think I identified the problem. For a superscript I, you are using the glyph name uni2071 and the matching Unicode.

That is not a simple superscript letter, but a “modifier letter.” I am not sure whether whatever InDesign is doing to it is correct, but I *am* sure that you shouldn't be mapping to that from a lowercase i with an ordinal feature applied. Just use an unencoded i.sups glyph and I bet your problem will go away.

BTW, many folks (including me) would argue that OpenType features should never change the character code. In this way of thinking, you should have a distinct glyph for the Spanish ordfeminine and ordmasculine, versus those that are accessed by a and o with ordinal or superscript applied.

Cheers,

T

John Hudson

BTW, many folks (including me) would argue that OpenType features should never change the character code.

This statement needs parsing, I think. OpenType Layout features never do change the character code, because they operate on Glyph IDs, not on character encoding. What Thomas means, I think, is that OpenType Layout features should not map to glyphs whose names point to character codes other than the original input.

It seems to me that an application applying OpenType Layout features should display the results of those feature lookups, and there isn't any grounds for the application to even care about the encoding identity, if any, of the output glyph. While Thomas' suggestion to map /i/ to /i.sups/, rather than to /uni2071/ may solve the problem, I'd say this indicates an application bug, because there is no good reason for InDesign not to display the /uni2071/ glyph as a result of this glyph substitution lookup.

Thomas Phinney

> What Thomas means, I think, is that OpenType Layout features should not map to glyphs whose names point to character codes other than the original input.

Yes.

And I agree that it seems InDesign is doing something odd with the glyph for modifier letter i (uni2071). But I think it is better practice to have and map to a distinct glyph, and I suspect that will resolve the InDesign problem at the same time.

yanone

No, sorry to report that the problem persists after renaming the target glyph to i.sups and removing its unicode value. I had tried this prior to posting, but I just reconfirmed.

Kent Lew

Yanone — When you say “InDesign 7.0.4” do you mean InDesign CS5 v.7.0.4? I still have a copy of that version running on my machine (OSX 10.6.8).

I just generated a test font with basically the same conditions you described and I am unable to recreate the problem. The only difference is that my glyphs happen to be named with .ordn suffix.

If you want to send me a copy of your source (VFB or UFO) and generated font, I will also be happy to take a look and see if I can a) recreate the problem here in my environment and, if so, b) help you figure out what’s causing it.

Denis Moyogo Jacquerye

The correct French abbreviation is 4^e, not 4^ième. At least that’s what style guides and grammar books will tell you. So maybe you could ignore this bug ;-)

Kent Lew

For the record, I was unable to recreate the problem on my machine with Yanone’s font and InDesign CS5 v 7.0.4. So, it is likely some local glitch — either with his app installation or the testing doc itself.

I sent a copy of my well-behaved InDesign doc to see if it continues to behave in his environment or not.

yanone

The result: All glyphs get correctly composed in my InDesign installation in the document that Kent created and sent me.
I’m still unaware what caused the glitch — I typed text and applied an OT feature. But it seems to be no broader bug. Resolved.
Thank you everyone.

Kent Lew

I want to come back to something Thomas said earlier:

For a superscript I, you are using the glyph name uni2071 and the matching Unicode.
That is not a simple superscript letter, but a “modifier letter.”

Is this really true? I look at the Unicode reference and I see that U+2071 Superscript Latin Small Letter i ≈ 0069 i.

How is this, then, not a reasonable codepoint to assign to a superscript i?

Is it really all that necessary or critical to duplicate the glyph — one named i.sups (and unencoded) for mapping via {sups} substitution and an identical duplicate named uni2071 (and thus encoded) for texts that are supplied with hard encoding?

Georg Seifert

About substituting to a glyph with a unicode. I was told that if you write a .ps file and distill a pdf from it, the glyph names are used to reconstruct the underlying unicode. This is the reason we care about glyph names in fonts.

I just tied to check this. I made a font that substitutes i by uni2071 and j by j.sups. Use it in an InDesign document and export as PDF. I used Preview.app and copied the text from the pdf and I got a "i" (not superscript). Then I wrote a .ps file and opened that in Preview (I do not have Distiller or Acrobat installed) and got the same result.
The PDF viewer in Chrome did what I actually expected and copied the superior glyph if it had a unicode and the base glyph if I used an unencoded ".subs" glyph.

For the superior glyphs I usually make a exception of the "do to substitute to encoded glyphs" rule. I think it is quite important to retain the superior letters if used in a text e.g. as footnote indicators.

Thomas Phinney

> Is this really true?

Yes. From the code chart: "functions as a modifier letter." Also, if it was intended as a generic superscript letter, there would be a ~ full set of them instead of only two (i and n) in the block.

From Unicode 6.2, pp. 236–237:

“Superscript Letters. Some of the modifier letters are superscript forms of other letters. The
most commonly occurring of these superscript letters are encoded in this block, but many
others, particularly for use in UPA, can be found in the Phonetic Extensions block
(U+1D00..U+1D7F) and in the Phonetic Extensions Supplement block
(U+1D80..U+1DBF). The superscript forms of the i and n letters can be found in the
Superscripts and Subscripts block (U+2070..U+209F). The fact that the latter two letters
contain the word “superscript” in their names instead of “modifier letter” is an historical
artifact of original sources for the characters, and is not intended to convey a functional
distinction in the use of these characters in the Unicode Standard.”

“Superscript modifier letters are intended for cases where the letters carry a specific meaning, as in phonetic transcription systems, and are not a substitute for generic styling mechanisms for superscripting of text, as for footnotes, mathematical and chemical expressions, and the like.”

Georg wrote: “ For the superior glyphs I usually make a exception of the "do to substitute to encoded glyphs" rule. I think it is quite important to retain the superior letters if used in a text e.g. as footnote indicators.”

How do you encode them?

Georg Seifert

My argument was more aiming at superscript figures e.g. /foursuperior (uni2074).

I was not aware of this. Thanks for pointing this out.

So the same is true for /hsuperior (uni02B0) to /ysuperior (uni02B8)? Then all the letter modifiers should be renamed to /imod, /hmod like /primemod?

Kent Lew

Yes. From the code chart: "functions as a modifier letter."

Ah, sorry: I was looking at an old Unicode 5.2 chart. Didn’t realize this had changed in the latest version of the standard.

Oy.

Thomas Phinney

Kent: Well, the intent was always there, but the details were not provided clearly.

Georg said: “My argument was more aiming at superscript figures e.g. /foursuperior (uni2074).”

Fair enough. Those are a bit of a different case. I still go with my Adobe-era practice of having separate glyphs for the encoded superscripts and subscripts in U+2070–U+2094 vs glyphs accessed via OpenType layout features. But that is a matter of choosing to preserve the backing store of the text, not because the encoded character is so distinctly “wrong.”

Georg asked “So the same is true for /hsuperior (uni02B0) to /ysuperior (uni02B8)?”

Yes, those are modifier letters as well (and have long been labeled as such).

“Then all the letter modifiers should be renamed to /imod, /hmod like /primemod?”

You are talking glyph names? Well, any newly invented glyph names like those are not AGL compliant, let alone AGLFN compliant. If you wanted to use those as temporary working names, well, whatever makes sense to you is good.

Georg Seifert

You are talking glyph names? Well, any newly invented glyph names like those are not AGL compliant, let alone AGLFN compliant. If you wanted to use those as temporary working names, well, whatever makes sense to you is good.

Yes. I was talking about the glyph names. I currently use the AGL names. But they are confusing in this case.

Denis Moyogo Jacquerye

AGLFN is better. Avoiding AGL-only names is a good idea nowadays.
Having /isuperior and /hsuperior is the same issue, they are mapped to modifier letters which happen to have superior letters as glyphs.

Thomas Phinney

What Denis said.

To expand on that: If you invent new glyph names like /imod and /hmod, they won't be recognized by much of anything. Use names of the form uniXXXX or i.something, at least in the final output font.

If you have infrastructure to make a distinction between internal working glyph names and final output names, of course you can make the working names whatever you like—the above comments are strictly about the names in the final font.

Interestingly, Mac OS X used to use glyph names rather than Unicode to determine the glyph encoding in OpenType CFF fonts. I think they eventually got away from that. But just to point out that there are some surprising uses of glyph names out there....

Mostafa Hajizadeh

If you have infrastructure to make a distinction between internal working glyph names and final output names, …

That would be very interesting.

How is this possible? Is there any UFO/AFDKO tool for doing this? (Or a program for post-processing final OTF files?)

Paul van der Laan

With the AFDKO one can rename any glyph when generating a font using makeotf. That's what the GlyphOrderAndAliasDB file is for.

Georg Seifert

In my case, this is all handled by Glyphs.app automatically. I keep a database that contains readable and production names. For most none Latin scrips I invented names like A-cy for the Cyrillic A (instead of afii10017).
And of cause, on export, it uses the production names.

Paul van der Laan

I thought the use of afiixxxxx names had been abandoned a long time ago? Even Adobe fonts from five years ago don’t use them anymore.

Georg Seifert

But I find them in user fonts all the time and they are used in a lot FLS encoding files.

John Hudson

For most none Latin scrips I invented names like A-cy for the Cyrillic A

For production glyph names -- as distinct from those written to final fonts --, I find it more useful to preface the names with a script identifier, rather than a suffix such as Georg shows. This makes it very easy to identify and select individual script portions of multiscript fonts. Also, there tends to be quite a lot happening in the latter portion of glyph names, for ligatures and variants suffixes etc., so putting the script identifier by itself at the beginning of the name helps keep things tidier.

If a script is casing, I put a . between the prefix and the glyph name, and sometimes do this to differentiate scripts too. My glyph names for non-casing scripts all begin with an uppercase, so for those a lowercase letter suffices as a prefix. When I get to the point where I have three scripts whose names begin with the same letter, I just make the prefix one character longer. To date, my prefix set is

a = Arabic
b = Bengali
c. = Cyrillic
d = Devanagari
g = Gujurati
h = Hebrew
g. = Gurmukhi
j = Javanese
k = Kannada
o = Odia (Oriya)
o. = Ogham
oc = Ol Chiki
m = Malayalam
s = Sinhalese
ss = Sora Sompeng
t = Telugu (also used as Thai in some fonts made for other foundries)
t. = Tamil
th = Thai
ti = Tibetan

I don't use a prefix for Greek because the customary letter names are not confusable with Latin glyph names.
______

I try to standardise production names as much as possible, so that I can leverage work in future projects, but some fonts call for unique naming conventions. The most fun I have had inventing glyph names was for the Aldhabi Arabic display type for Microsoft, which includes great names like these:

B.medi.a.3_0
B.medi.b.3_1
B.medi.c.3_2
B.medi.d.3_3
B.medi.e.3_4
B.medi.f.3_5
B.medi.g.3_6
B.medi.h.3_7
B.medi.i.3_1
B.medi.j.3_2
B.medi.k.3_3
B.medi.l.3_2
B.medi.m.3_4
B.medi.n.3_7

These names contain a collection of information that I could later use to generate some fairly complex OpenType Layout data.