I have a feeling that the "right" answer is deep in the software issue. From the OT features registry under ccmp:

. . . The feature should be processed as the first feature processed . . . This allows the font vendor to do special handling of the mark combination when doing further processing without requiring larger contextual rules.

Other issues might be what software supports `mark' vs `ccmp'. I have always used ccmp for glyphs that do not have a precomposed Unicode slot, primarily because Adam Twardoch used that when he wrote a bit on how to make us these characters & the associated code for an old "Fontlab tips" article.

http://groups.msn.com/fontlab/tipsandtricks.msnw?action=get_message&mvie...

You might even consider audience. Putting on my asbestos suit, I'd say there is a certain group who will enter any character other that a-z by using the glyph pallet. And another group who, if the character is in Latin Extended A or B, will just enter the Unicode string

There are pros and cons to both approaches.

If you use ccmp instead of mark positioning, then you need to include a precomposed glyph for every diacritic combination that you want to support. That may be a lot of glyphs, and you're left not supporting any combinations beyond that set. On the other hand, GSUB is faster to process than GPOS, so the font will be quicker, and although it is arduous to kern all those diacritic combinations -- especially exceptions to the class kerning -- it is relatively straightfoward to do so.

If you use the mark feature instead of the ccmp feature, you get the benefit of much greater flexibility, being able to support arbitrary diacritic combinations. You also don't have to create all those precomposed glyphs. The biggest downside to mark positioning, I think, is trying to integrate it with kerning. Imagine: you have an uppercase T followed by an i with a dynamically positioned combining mark above; you have to specify the kerning contextually, with the combining mark(s) as context. Or a more complicated situation: you have two narrow letters, both of which have dynamically positioned combining marks above and the marks are wide enough to clash; you have to contextually increase the spacing of one of the letters in context of the other letter + the marks. I've done this for Arabic and Thai, and am in the process of doing it for Biblical Hebrew, and it's not fun. [In fact, there's probably only one aspect of OTL development that is less fun. I'll see if you can guess what it is.]

Of course, you can employ a combination of ccmp and mark features. This gets you the pros and cons of both, but with some added work: you need to include mark positioning not only for the base glyphs but also for all the precomposed diacritics in the ccmp lookups, since the mark feature should support arbitrary sequences including those diacritics.

you have to specify the kerning contextually, with the combining mark(s) as context.

are there any applications that currently support this?

Do you mean applications for making fonts, or applications for setting text?

You can program contextual kerning in VOLT. I'm not sure whether you can do so in FL/FDK; I suspect the syntax supports it, but I don't know whether it will compile.

I have not tested contextual kerning for the Latin script in ID CS3, but that would be the most likely place it would work. I've use contextual kerning extensively in Arabic fonts, and this works in MS Office, OpenOffice, ID ME, etc.

My understanding is that the current FDK supports contextual kerning, although we haven't been using it in our own fonts, except for testing.

Cheers,

T

Contextual kerning works in FDK and InDesign CS2/CS3. I use it since some time now in Latin fonts.

FYI, note also that mark attachment works in Windows Uniscribe applications, and in InDesign CS3. It does not work AFAIK in OS X, and does not work in most other Adobe creative apps up to CS3 versions.

'ccmp' is supported in Windows Uniscribe apps, and in InDesign CS3, but not in earlier versions of InDesign, nor by most Adobe creative apps. Not sure about Mac OS support of this feature.

Cheers,

T

This thread is a couple of years old, so I imagine support for "mark" feature is more extensive now. Anyone care to update this list of which software supports which features?

I'm in the midst of creating a font to be used for IPA transcription by run-of-the-mill Linguistics students. This means that all the diacritics need to be rendered correctly by such environments as MS Word 2003 running on Win XP. Is "ccmp" with GSUB my only option here to align base glyphs of varying widths with diacrtics? Descenders are also always an issue.

I heard that Open Office is supposed to be supporting more font features with its next release sometime Fall of 09. Anyone know if it will support base to mark features?

CCMP Vs MARK

CCMP = Compose DeCompose Feature. what ever is attached to CCMP will allways happen

MARK is controled in the Diacritic Positioning windows in indesign
when changed from normal to Opentype MARK Feature is activated

in WORD MARK Feature is allways activated

I believe "mark" and "mkmk" are not yet supported by FontLab. I can't compile a font with these features (in FontLab Studio 5). Perhaps my ignorance?

Charles, this is correct. You need to use either the newer standalone version of the Adobe FDK, or the MS VOLT tool. I use the latter for all my OTL work.

Chares_e: I use MSVolt mainly
in hebrew fonts that i develop i use masiv Mark2Mark
attaching hebrew cantillation notes to diacritics

they are all attached to the event
so ither there is no difference or volt automaticly somehow interpets this lookups to mkmk

however, i do not C any differnce/