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


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.



  • Nick ShinnNick Shinn Posts: 2,128
    edited January 2019
    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.
  • 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 PhinneyThomas Phinney Posts: 2,704
    edited January 2019
    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.  :#  )
  • @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.
  • 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.
  • 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. 
Sign In or Register to comment.