CCMP one-to-many InDesign

I have a feature that decomposes some accented glyphs, for example Aogonek to A + combining ogonek. This works as expected in Chrome, but it doesn’t work in InDesign – not even if I use the World-Ready composer. The underlying text still shows one character: 0x104. Is this expected behaviour, or is there something wrong on my side?


  • The underlying text still shows one character.

    That is because features are not supposed to change the underlying text, only the derived glyphs. I would suggest testing the ccmp by changing the look of one of the decomposed glyphs, so that you can tell immediately when you see it.
  • Eric is right: there are two distinct operations: the Unicode decomposition (into the NFD form where accented are encoded as basic letters followed by combining marks; you can convert your text into NFD using Unicode Checker's Tools palette), and glyph one-to-many substitution (via "ccmp" or any other feature, which will do whatever you put into the font). The latter will not influence your character codes. 

    Note that some apps automatically convert your text into NFC (composed) form behind the scenes, so testing "ccmp" in apps may prove a bit tricky. 
  • Aha! InDesign is “re-composing” the separate parts again.
  • That is true, InDesign likes to default to the precomposed glyph if it is available for the respective letter+mark combo. You could circumvent that by adding another combining mark, because it only des that when there is a single mark following a letter, IIRC.
  • Kent LewKent Lew Posts: 763
    because it only des that when there is a single mark following a letter, IIRC.

    That’s only true with InDesign’s standard composer. A second combining accent will break up the automatic composition of the base and the first (unless, of course, there is a relevant double-accent combined NFC codepoint — Vietnamese, for instance — and the encoded glyph is present).

    In the same situation, the World-Ready composer will maintain the first composed glyph and just place the second combining accent.

    BTW, there’s an additional difference in the handling of combining accents between InDesign’s standard composer and the World-Ready composer. While both appear to prefer precomposed glyphs when the corresponding NFC codepoint is available in the font, they behave differently when one is not.

    If there is not a {mark} feature to manage the positioning of a combining accent, then the standard composer will place the zero-width glyph at the advance width (right sidebearing) of the previous glyph. The World-Ready composer, on the other hand, will center it on the advance width of the previous glyph.

  • Kent LewKent Lew Posts: 763
    P.S. Note that World-Ready composer appears to center the *bounding box* of the combining accent on the advance width of the base glyph in these situations. So it yields the same results regardless of whether the font employs a strategy of offsetting combining accents to the left or just has them centered on the zero point.
  • Chris LozosChris Lozos Posts: 1,080
    If InD doesn't even do it properly, what apps can you count on to do it right?
  • edited August 2015
    Is there any way to inspect what is actually happening to the “derived” text behind the scene in InDesign? Or browsers, for that matter?
  • Adam TwardochAdam Twardoch Posts: 397
    edited August 2015
    Čĥĕčķ őúť váŕĩőúś “fáńčŷ ťĕжť” ğĕńĕŕáťőŕś*, ťĥĕń úśĕ Uńĩčőďĕ Cĥĕčķĕŕ’ś Diff, Normalize áńď Split Up úťĩĺĩťĩĕś. Diff áńď Split Up áĺĺőŵ ŷőú ťő śĕĕ ťĥĕ čőďĕpőĩńťś ĩń á ťĕжť, áńď Normalize áĺĺőŵś ŷőú ťő čőńvĕŕť ßĕťŵĕĕń NFC áńď NFD. 


    A. :)
  • BTW, this tool is good for testing mark attachment: :) 
  • Haha. Thanks!
  • I've found BabelPad by Andrew West to be very helpful in understanding what is going on at character-level and glyph-level.
    (Windows only)
Sign In or Register to comment.