Combining accents in future fonts
The main reason for having combining accents in a font is if you also have mark attachment information in the same font, so as to actually support positioning the diacritic relative to a base letter.
Currently none of Adobe’s western fonts support this functionality. There are several reasons for this:
1) Prior to InDesign CS3, none of Adobe’s flagship creative graphics/publishing applications supported mark attachment in the regular western version.
2) Adobe’s FDK (and thus FontLab) don’t yet support mark attachment, so it was not easy for us to do in OpenType CFF fonts.
3) it’s more challenging to do the contextual kerning required to kern these dynamically combined accented letters.
So, with InDesign CS3 out, we now have an Adobe app that can use this functionality.
Moving forwards, for most of the language support we have done before, we will continue to use prcomposed accents. But for more extended language support, which we are starting to work on now, we will use OpenType mark attachment (‘mark’, ‘mkmk’ and ‘mlig’ features as appropriate).
As you might guess from that, we’ll be enabling this by adding support for mark attachment to our own Adobe FDK for OpenType, which also yields source code for FontLab and DTL FontMaster. I can’t give you a clear timeline, but I’ll say that the fact we want to use the functionality ourselves increases the priority of getting it into our tools.
2 Responses
Comments are closed.
Oh! Monday news, good news!
Is a stopgap measure worth the trouble? In terms of searching and fidelity of electronic versions, precomposed are absolutely the way to go.Is unicode all that bad?[Unicode says that where precomposed forms exist, they are canonically equivalent to the decomposed forms. In some cases, no precomposed forms exist as Unicode characters; in these cases, whether the font handles these in a ligature-like fashion or with separate glyphs makes no difference to the searchability of the text. In cases where both forms are valid, a well-formed search routine should treat them as canonically equivalent. I should add that I think Unicode is reasonable in its fundamental principle of not adding new accented character combinations when they can be handled by combining accents. – T]