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.
28 Responses
Comments are closed.
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.Man, I was all set to make a joke about finally being able to properly set Spinal Tap’s name with an umlaut over the n, and then Wikipedia tells me this:The n with an umlaut exists in the minor Jacaltec language of Guatemala and the Malagasy tongue, where it represents a velar nasal consonant.A nerdy joke ruined by even nerdier new knowledge. Harumph.
This is really great news! Does this mean we won’t see these features in Photoshop and Illustrator?[Yes, these new features are specific to InDesign as far as I know. – T]
I would like to know whether CS3 now supports Indic scripts (e.g. Devanagari etc.) as Volt-created OpenType fonts, e.g. the Devangari fonts freely downloadable from my Sanskrit website.[No, the regular version of InDesign CS3 does not support any “complex script” languages such as the Indic languages. Nor does it support right-to-left languages such as Arabic and Hebrew. – T]
Thomas, you wrote “In the upcoming Hypatia Sans I also used it to get steeper acute accents on capitals for Polish and Czech.”I am afraid this is a misunderstanding. There is absolutely no preference for steeper acute accents on capitals in Czech language. Please check typefaces designed by Czech type designers (Frantisek Storm, Tomas Brousil, Oldrich Menhart) and you realize that not the steeper acute but the flatter form is preferred! According to Adam Twardoch, Polish designers prefer steeper acutes. What could be true for Polish is not true in case of Czech language.The Czech acute could be very flat or very steep, it depends on the character of each typeface. We prefer accents to be harmonized with the typeface rather than follow very detailed rules.The reason why upper case accents are usually drawn flatter is simple. Czech (and Slovak) languages do have a lot of diacritical marks. And upper case diacritics often collide with descenders of the previous line of text. Flattening of accents (not only acute, the caron is usually flattened too) is a nice and elegant solution.If you want me to send you some scans of Czech diacritics, I will gladly provide you with them.[I’d be interested in the scans, but I know you and am perfectly willing to take your word for it as well. Drats. Seems like something I would hope to address in a dot release, probably about the same time the italics are done. – T]
I like the improvements in the Glyph panel. Here’s a suggestion for future updates. Typically when English-language users are inserting non-Roman characters, we know the language it’s in–German, French or whatever. Unfortunately the Glyph panel doesn’t offer us those sets, so we ending up hunting for just the right little mark with strained eyes.If it’s doable, it’d be great if Glyph had Show selections for the more common languages. Extended Latin A & B helps. But it’d better to go directly to a speciflc language’s characters and only those. The feature would also help in cases where two languages have very similar-looking characters with different Unicode assignments.[Thanks for the suggestion, I like it! – T]
Had anybody used Hindi, Oriya or any other Indic Language’s Unicode(UTF8) Open Type Fonts text/graphics in Indesign CS3? If yes, the characters/syllables are rendering perfectly? Is the search-replace, sorting indexing features are also working perfectly? Kindly inform.[With CS3, InDesign does not yet support the proper shaping behaviors required for Indic languages (nor dictionaries, sorting, etc.). It’s certainly something we’ve been looking at, though. – T]
You write:All 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 […]This is not true.I was checked Pro fonts in ID CS3 with installed Romanian keyboard. This function work only with: Arno Pro, Bickham Script Pro, Adobe Caslon Pro, Garamond Premier Pro, Adobe Garamond Pro, Minion Pro, and — of course — Hypatia Sans Pro.[Rats, it seems you are correct! Of course, these days Romanian keyboard drivers use the newer, distinct codepoint for S comma accent, so I think of this as more of an academic point and a nice-to-have feature rather than a critical font feature. But the main point remains, that InDesign will do this language-sensitive processing based on the information in the font. Thanks for the correction! – T]
You say that InDesign CS3 supports all Unicode modes, but when importing text, I cannot for the life of me get it to import UTF8. It does UTF-16 just fine of course, but no form of UTF8 works (with BOM, without BOM)–it insists on treating it as some 8-bit national encoding. So how exactly is this different from CS2?[Ack, you are entirely correct. I was told this was supported, and ran this posting by some folks on the InDesign team to make sure my details were correct, but somehow got this wrong. I’ll correct the original post appropriately. – T]
Still InDesign does not support fully Hindi, Gujarati, Oriya etc. Indic scripts. If you have any info about satisfied Hindi users of it, kindly let me know at hariraama@gmail.com[Yes, that’s correct – as also mentioned above in Ulrich’s comment of April 9th. The Indic languages are very high on our list of other languages we would like to support, but we’re not there yet. – T]
Is it possible to layout Unicode Devanagari text in any version of InDesign under OSX? If yes, then with which font(s)?[I don’t think it is possible, due to lack of automated support for some of the features involved in doing that layout (beyond than just rendering something for each Unicode codepoint). If it is possible, it would require very painful manual work with the InDesign glyph palette. – T]
If InDesign CS3 uses the “locl” feature, how is it triggered? By specifying the dictionary for text, by changing the keyboard layout, or what?[By specifying the dictionary for text. (Changing the keyboard layout wouldn’t work for imported or existing text, and one can type in multiple languages with the same keyboard layout.) – T]Last year I tried to develop fonts that displayed different characters based on the applied language, but it didn’t work in CS2.I would need this to work transparently in CS3 apps on both PCs and Macs, as well as embed properly in PDFs.[As far as I know that should be true today, in InDesign CS3. However, that’s the only Creative Suite app that supports this, so far. – T]Thanks for any additional info or pointers to a technical description of the locl feature implementation.[The OpenType specification and our own implementation in recent fonts such as Arno should be useful references. – T]Darryl
Thanks for sharing your knowledge in a non-geek way!I’m just starting to investigate using InDesign for Devanagari, and understand that it’s not quite there yet. Could you give us an idea of the future, i.e. how soon it is expected? Or will you rely on Apple including the necessary features into the OS?[Good question, but I’m afraid that’s the kind of future plans I can’t really comment on very much, Except to say that we are aware of the demand for Devanagari and other Indic languages. What I can say is that we would be highly unlikely to rely on OS-level language support, because it’s important to us to get consistent cross-platform results. – T]
Thanks! I understand… Yes, in the mean time I found out that you are working with your own implementation, not Uniscribe/ATSUI. Somehow stupid that such a cross-platform implementation was not planned right after Unicode was conceived.Could you make a wild guess how likely it is that Adobe’s implementation (does it have a name?) will eventually become available as a stand-alone package, so that users can install it on their Windows or Mac OS?Adobe has a record of creating really good solutions which fail to take over the world because they are kept too closely guarded…By the way, for the other posters: One (expensive) solution for using Indic script in InDesign I’ve found is Summit Indica, available for Mac and Windows. Conversion to&from Unicode seems to be possible with FontSuvidha.[This is purely speculation on my part, but I can say that implementing this sort of stuff involves work both in Adobe’s text engines and in various support libraries. I would be surprised if it were easy to extract all that work into a separate library, more surprised if it was easy for third parties to adopt, and even more surprised if Adobe had any reason to do such a thing. Instead, perhaps you should check out IBM Components for Unicode (ICU) and see if that either meets the needs in question or could be extended until it did. – T]
About the locl feature:Did you see this page:http://www.microsoft.com/typography/Glyph%20Processing/detail.mspxScroll down a bit to the section “Scripts and Language Systems”
Thanks a lot for mentioning ICU — I’m learning!But wait, let me think… Does this mean that, if Adobe’s corporate consciousness would have been on a slightly higher level, your Board of Directors could have decided to contribute to ICU (even though it was unclear what the returns on that investment would be), bring ICU to a point where InDesign could be based on it, and make this typesetting world a better place?I know, I’m a dreamer…[Actually, I hear that we have contributed or are contributing a few small things towards ICU. InDesign does use some code from ICU, but “be based on” is not a particularly plausible concept. Adobe has contributed to open source software, and in some cass donated large libraries, but I don’t think this would be practical. Mind you, I’m not a real programmer, so I could be wrong…. – T]
Speaking of text features, am I right that InDesign CS3’s glyph palette sorts by Unicode value and glyph name (for variants), instead of GID, like before? Illustrator CS3 appears to sort by GID.[I believe you’re correct. – T]
Michael Perry posted:”… we know the language it’s in–German, French or whatever. Unfortunately the Glyph panel doesn’t offer us those sets, so we end up hunting for just the right little mark with strained eyes.”Apple is being pressed privately, publicly, and politically to implement a subsetting mechanism in the Character Palette in order to support the multilingual European Union with the equivalent of ICC working spaces.The Common Locale Data Repository, of which Deborah Goldsmith is currently chair, has a concept of example character subsets for locales, but the concept is not exposed in the simple subsetting mechanism of Favourites in the Character Palette of Mac OS X 10.4.Henrik Holmegaardtechnical writer, mag.scient.soc.
I remember when the first incarnation of InDesign was released with Unicode support back in 1999. I thought that at last, all the problems with multilingual publishing would be solved. Yet, seven years later, a single unified InDesign with CJK, Indic and Bidi support is still a pipe dream.However, the irony is that the humble browser has solved most of the problems and that Quark is even further behind.
Ge,Could you expand on use of Indic in InDesign with Summit Indica? I checked out their website and nothing there seems to offer such support.
Sorry, Gadi, it’s a long time since I visited this site! Just in case you’re watching:Summit works with 255-slot fonts and their Indica software takes care of the input and typography. Therefore, they are completely independent of Unicode.Actually, they were already on the market in the Mac OS 7 days, if I remember correctly, and both the font and the internal workings seem to be exactly the same still.
Hi all,I’m a bit surprised that nobody mentions the Central European or Middle Eastern versions of InDesign CS3. Indeed, these versions, available from WinSoft, perfectly support Middle Eastern (Arabic, Hebrew) and Central European (Czech, Greek, Polish, Hungarian, Romanian, Russian, Turkish, Ukrainian) languages .More info and tryout: http://www.winsoft.eu/products_solutions/adobe-indesignCS3.phpMaud%5BThese are outstanding products, and we’re always pleased to refer people to them when they’re looking for middle eastern or eastern European language support. – T]
I realize that your ability to comment on future business plans is limited. If you can tell us: Does Adobe plan to leave Middle Eastern language support to the WinSoft versions forever? Are there no plans to include Arabic support the way that it seems Indic-language support may be added? Thanks.[I’m afraid I can’t talk about this much, no. I’ll just say that we recognize the value in having a single version of an app that supports lots of languages. – T]
IMO it makes no real sense to have different ME, Indic and CJK versions.India needs “Arabic” support as well as support for “Indic” scripts – India after all has a huge Urdu speaking population.There must be a similar situation in SE Asia where they may need support for Han (CJK) as well as Thai/Lao/Khmer.Different minority scripts in China (Tibetan, Monglian etc) have shaping requirements very different than CJK.
I have a question which has probably been mentioned here but not fully.I am using Indesign CS2 and I urgently need a right to left text settings. Can someone give me a link where a tool for this support can be downloaded. Some time ago I have downloaded it, and my actual documents are already aligned correctly. But then I’ve lost that tool and now unable to make edits to the right-to-left arranges indd files. Thank you so much for your help!!!!!!!!![Only the ME version of InDesign CS2 supports right-to-left composition. Perhaps what you used was the IndicPlus plug-in by MetaDesign – M]
My friend is using CS3 InDesign, there are one problem and it is that Page numbering is not working in Tibetan Unicode.We have follow the Unicode Consortium Rule by applying the Code of 0F21 for 1 number and similarly 0F22 for 2 number but it is not working. Any suggestion please.[InDesign CS3’s page numbering does not support Tibetan numerals – MS]
Hi LobsangTibetan and other Asian Unicode languages are very well supported in a third party plug-in for Adobe InDesign, InCopy and Illustrator. The plug-in is named IndicPlus. You can read more about it at http://www.metadesignsolutions.com/indicPlus. It supports literally all Unicode fonts.These guys also have a free trial version. Hope this helps.[It’s possible to enable the World-Ready Composer in CS4 and CS5 versions of InDesign, Photoshop and Illustrator. For more details ready Thomas Phinney’s post at http://www.thomasphinney.com/2009/01/adobe-world-ready-composer/ . Noteworthy is also WinSoft’s ScribeDOOR http://www.winsoft-international.com/en/products/scribedoor-for-indesign.html — MS]
Can Adobe CS4 and CS5 text engine handle one-to-many substitutions?[In terms of the flagship applications—InDesign, Illustrator, and Photoshop—the answer is yes and no.First, to elaborate on the “no” answer, the text engines that are used by default, such as in the English language versions of the products, do not support one-to-n substitutions (aka, ligature decomposition).Next, to elaborate on the “yes” answer, if the World-Ready Composer is used, one-to-n substitutions are supported, if the selected font includes them, and if it is a GSUB feature that the application supports as part of its UI. The ME (Middle East) versions of our applications directly expose the World-Ready Composer, and to do so using the non-ME versions requires effort on the user’s part. One way is to download and use the templates in Thomas Phinney’s “World-Ready Composer in Adobe CS4” blog article. See: http://www.thomasphinney.com/2009/01/adobe-world-ready-composer/The other way is to purchase WinSoft’s ScribeDOOR for CS4. See: http://www.winsoft-international.com/en/products/scribedoor-for-creative-suite-4 .htmlI believe that what I wrote above applies to both CS4 and CS5, though the CS5 versions of the applications were used to confirm this behavior. It is also useful to point out that if you are using Mac OS X, TextEdit supports one-to-n substitutions. — KL]
I have had trouble getting a halftone dot to print out from InDesign CS3 but I have discovered a way to get it done. Open halftone in PS and make grayscale. Go to filter gallery and choose halftone. You can adjust the dot. Save and place into InDesign, the dot will stay with it and print out.
This dot is necessary for older paper plates systems.
To get a dot in a screened area of a form. Use Freehand or Illustrator. Draw a box with no stroke but use a pattern fill. There are 3 dot patterns to choose from. Place on form in InDesign and size to fit the area you need the screen in and send it to the back. Works great!