InDesign CS3 new font/text features
Adobe InDesign® CS3 has a ton of new features, many of which can be seen on its Web site. But there are also many features that aren’t quite big enough to be seen on that august location. I thought I’d mention a few of them that are of particular interest to my fellow font geeks.
Most of the enhancements I’m thinking of relate to language support and linguistic processing of text with OpenType fonts. These include support for the following OpenType layout features
mark attachment. The features mark, mkmk, mset are used to dynamically attach diacritics to base characters. This is required for some languages, and useful for font developers to have the option to provide fonts that use dynamic mark attachment rather than providing all accented characters as precomposed glyphs.
“required” ligatures (rlig) needed for some languages
canonical composition/decomposition (ccmp) of characters to glyphs. Note however that the InDesign text engine still can’t handle one-to-many substitutions, so something like turning a German eszett into two small cap esses in the ‘smcp’ feature still doesn’t work – however the text engine takes care of known situations like that anyway, so no problem there.
locale-specific alternates (‘locl’) needed for correct treatment of many languages, including some CE languages such as Romanian, Turkish and Serbian.
All our italic Cyrillic fonts also use ‘locl’ to switch about four letters from their more standard shapes to one preferred for Serbian. In the upcoming Hypatia Sans I also used it to get steeper acute accents on capitals for Polish (and for Czech, unnecessarily).
Many of Adobe’s “Pro” fonts have the ‘locl’ feature to get the proper distinction between the Romanian S with comma accent and the Turkish S with cedilla. Mind you, these now have distinct slots in Unicode, which are not used by newer Windows and Mac codepages and keyboards.
[updated 18 June 2007 to reflect current Mac/Win keyboard behaviors and that not all Adobe Pro fonts have this. Also updated earlier reference to Czech.]
Besides the specific features being supported, InDesign is now doing language-specific processing of OpenType features, which helps with a lot of this. However, this is not the same as actually supporting the Indic languages, Arabic, or right-to-left text in the main version of the application. It’s a step in the right direction, though!
Folks who make and use script fonts will be thrilled to hear that ID CS3 now supports “positional forms,” where letters get different initial, medial, final or isolated forms automatically assigned by the text engine based on their position in a word. This is a requirement for proper Arabic support, but really nice to have for high-end script fonts as well. A lot of things that would otherwise require fancy contextual programming can now be done much more simply by the font developer.
What about bug fixes and other kinds of enhancements? Well, one morning just a couple of weeks ago, I was working feverishly on my new typeface Hypatia Sans Pro (about which more in a near-future posting). I needed some printed proofs and was trying to set some text in InDesign CS2. First, I noted a couple of issues with the polytonic Greek setting – but these were InDesign, not the fonts. “Hey, those are fixed in CS3,” I thought. “I wish I had it on this laptop and not just on a desktop machine back at the office.” Then I went to try out some other international text. I thought I’d just grab some Unicode text files from the “UN Declaration of Human Rights (UDHR) in Unicode” site, which is great for this sort of thing. But they didn’t place correctly. Then I remembered that InDesign CS2 can only place Unicode text files if they are UTF-16 encoded, and sure enough, it turned out that these files were UTF-8 encoded. [Update 18 June 2007: sadly, this is still a limitation in CS3, I had thought it was getting fixed.]
There are tons of other new text features in InDesign CS3, from text variables to improvements in bullets and numbering. Most of them are getting plenty of attention in the official web site. For instance, they at least mention the awesomely powerful support for GREP based search and replace. What I didn’t see was mention that you can know even do searches (and replaces) on glyphs rather than characters. So it doesn’t matter how a glyph is stored in a font or in text, you should know be able to search for and replace with that glyph if you need to. Very cool.