Consideration of ‘space’ within calt in Adobe Apps vs. Mac OS X

Martin Wenzel

Hi,

I got the following simple calt feature that triggers a change in a sequence of three (or more) glyphs:

feature calt {

    @Normal = [a space];
    @Special = [a.special space.special];
    sub @Normal' @Normal @Normal by @Special;
    sub @Special @Normal' by @Special;

} calt;

This should result in the following:

    /a  ->  /a

    /a/a  -> /a/a

    /a/a/a  ->  /a.special/a.special/a.special   

    /a/space/a  ->  /a.special/space.special/a.special

The feature works like a charm in any native Mac OS X App (FontBook, TextEdit, …) as well as RoboFont (FeaturesPreview). However, in InDesign or Illustrator I get a different Result and the substitution already starts to happen with a sequence of two (or more) glyphs:

    /a  -> /a

    /a/a  ->  /a.special/a.special  # wrong!

    /a/a/a  ->  /a.special/a.special/a.special

    /a/space/a  ->  /a.special/space.special/a.special

Only when I remove ‘space’ from @Normal (and of course ‘space.special’ from @Special) do the Adobe apps work as expected and show:

    /a  ->  /a

    /a/a  -> /a/a

    /a/a/a  ->  /a.special/a.special/a.special

Does anyone know of this issue? Is this a known InDesign/Illustrator/Adobe bug?

Even when I increase the length of the sequence the effect is the same. Thus when I define a sequence of six glyphs InDesign will take only five glyphs to substitute the glyphs.

Thanks,

Martin

Nick Shinn

Better not to include the space character in substitution code, because certain applications have another way of determining spacing in certain situations.

Use the <ignore> method of feature coding instead.

Erwin Denissen

I was not aware of this issue, but last November we did notice an issue with Edge that resets after two spaces.

I've added your findings to our list of OpenType Layout Feature Support Differences.

Thomas Phinney

I am curious, is the font in question a script font, or a more normal body text face, or...?

So, the underlying problem is that while Adobe does treat the space character correctly as far as using its width, newer versions of Adobe text engines do NOT use it in OpenType layout (as in, substitution, etc.). Performance reasons were the motivation for the change.

This was first done in a text engine used in one of Adobe’s more peripheral products, but I guess the others got it eventually as well, seeing as InDesign and Illustrator use two different text engines.

One might argue that it is okay for anyone laying text in Bickham Script to suffer a little slow-down if they set a whole chapter in the font, in favor of getting the actually desired glyphs all the time, including in display text.

(Adobe peeps: feel free to contact me if you you want details about the history.    )

Martin Wenzel

@Thomas Phinney thanks for your feedback. The font in question is a Sans for use in headlines.

Strangely InDesign (or Illustrator) do replace the space correctly, but before the defined sequence length has been reached. For example: InDesign will replace the space if it's the 5th glyph even though I have defined a sequence length of 6.

Jens Kutilek

It seems that InDesign adds an additional space at the end of a line, so when you type /a/a, InDesign sees /a/a/space and triggers the substitution. If another character follows, e.g. /a/a/b, none of the 'a's is substituted.

Ben Kiel

One other thing about the space glyph in InDesign (at least), it seems that at some point the text engine decided that it wouldn't swap the space glyph for another glyph with a unicode code point, so if you have a fraction feature that swaps the space for a thin space, this stopped working. If you have a un-encoded glyph, say 'space.frac', all is well.

Thomas Phinney

Hmmm. OK, I think I did not read the description carefully enough. Presumably this is a different problem—and the particular issue I wrote about has not infected other text engines at Adobe. That would be a good thing, IMO.