What is the better kerning option (Optical/Metrics) for xml workflow in Indesign? Usually, it is said that 'Optical' kerning is best in Indesign. But, when I set this option to an xml workflow job that has combined characters or some special characters, I encountered Indesign hangup issue (but not everytime). After I changed the kerning to 'Metrics', it goes well. Please note that, I didn't face this kind of kerning issue in the non-xml workflow. Is xml and non-xml workflow related to kerning method in anyway?
Lucky Siva wrote:
Usually, it is said that 'Optical' kerning is best in Indesign.
Funny, it's always been my understanding that for a well-made font metrics is the correct choice and that optical kerning is intended to work better only when combining glyphs from different faces or different styles of the same face.
As Peter notes, there is no clear concensus that Optical kerning is the better choice. But it is a question of the particular font(s)/face(s) involved as well as some degree of personal preference and artistic sensibility.
But it is quite a surprise that you see different kerning between XML and non-XML workflows.
Can you gives us a very narrow example? Show a screenshot of some text that has kerned incorrectly in an XML workflow, and then type that same text in a non-XML workflow and show that the problem does not persist? That sounds like unexpected behavior!
Peter Spier wrote:
Lucky Siva wrote:
Usually, it is said that 'Optical' kerning is best in Indesign.
Funny, it's always been my understanding that for a well-made font metrics is the correct choice and that optical kerning is intended to work better only when combining glyphs from different faces or different styles of the same face.
Sorry, I don't understand what are you suggesting.
Can you please go through the below links for me?
http://printplanet.com/forums/adobe/17486-metrics-vs-optical-kerning-i ndesign-cs3
-------------------------------------------------------
"It's a "yes" and "no" answer.
Yes, optical kerning is visually "better" or more "pleasing" because 1) it's automatic and 2) designers in general prefer tighter spacing between letter.
No, this is purely based on designer's opinion. Your average reader will never know any difference nor care about tighter kerning or not and certainly depends on the font used as well.
Frankly, if you really want to find out what setting is better for type in general, find an experience old-school typographer with eagle-eyes and run a few setups using different fonts you used the most with a mixed of optical/metric kerning. It'll still be he/her opinion, but here is where I trust old-school skills better than technology. BTW, our in-house old-school typographer also prefer optical kerning, but again, there are cases where it doesn't work well on certain typefaces.
-----------------------------------------------------------
http://www.mombu.com/computer_design/indesign/t-optical-vs-metric-kern ing-13349912.html
John Hawkinson wrote:
But it is quite a surprise that you see different kerning between XML and non-XML workflows.
Can you gives us a very narrow example? Show a screenshot of some text that has kerned incorrectly in an XML workflow, and then type that same text in a non-XML workflow and show that the problem does not persist? That sounds like unexpected behavior!
I didn't mean different kerning between xml andnon-xml workflows. Sorry If I was not clear. I said "Indesign hangedup or crashed" when a job with optical kerning, combined characters, special characters in XML workflow. Hope this is fine.
I think those two threads highlight that this is a subject where everyone has an opinion, and that what's right depends on who is giving the answer.
I'm much more in the Dominic Hurley camp. If a typographer has built kerning into letter pairs, who am I to say he's wrong and that an algorithm is better than the designer's judgement about the desired look? Certainly there are fonts that didn't get much attention to kerning, and even fonts that you might think one or two pairs are too tight or too loose, but that doesn't mean you throw out the baby with the bath water. And there are faces, like a lot of scripts, for which anything but metrics is a disaster.
I wouldn't say that two discussions involving a handful of users constitutes a consensus, even if they all agreed (unless, of course, they all agreed with me
).
But, when I set this option to an xml workflow job that has combined characters or some special characters, I encountered Indesign hangup issue (but not everytime).
If it's intermittent, then the hang might not be caused by your "combined or some special characters" but I would agree that this is the first place to look. But I wonder what these "combined" characters are - can you give specific examples? Because I have experienced intermittent impossible-to-nail-down hangs with some not-vanilla-Latinscripts and Optical kerning - notably, when handling Vietnamese or non-Russian extended-Cyrillic texts keyed with combining accents.
Thanks Pete.
But I think I moved you all to out of track.
1) I received complaints from Indesign composers that Indesign got hangedup or crashed when an application with optical kerning, combined and/or special characters in XML workflow rather than if the kerning is in "Metrics". Therefore, we have decided to set only Metrics kerning for the xml-workflow templates.
2) Moreover, our composers feel that they need to track the combining characters extra if it is in Optical and not in the case of Metrics kerning. Please refer to the below image. The dot above "n" is a combining character of different font.
I'd appreciate if any clear and convincing answer.
Thanks for all of your patience.
It crashes if you use Optical kerning. It looks ugly! if you use Optical kerning. Don't use optical kerning!
However, I would suggest this not as a policy, but as a troubleshooting technique. If your hangs and/or crashes stop happening as a result of forbidding optical kerning in your workflow, then at that point it can become a policy, and hopefully a bug report to Adobe as well.
I think I recall someone trustworthy, maybe Thomas Phinney? explain how it was supposedly useful when setting text at large headline sizes, if the designer's kerning pairs were intended for text set at body-text sizes. It was in a discussion about the profusion of faces in recent Adobe fonts, where there would be a Captions set, a Headlines set, and so on. Speaking personally, I hate the way optical kerning looks on body text. Old people (in my job, that mostly means old Russians) complain to me that it's harder to read; someday I'll do a readability study. Tightly-set text is, I think, harder to read, and leads to lower comprehension, and designers tend to use optical kerning as a shortcut to fit more text in a given space. This is opinion, once again, but it's my opinion derived from handling the work of hundreds of different designers over the last decade in a translation firm.
Finally - so, you're doing Sanskrit transliterations, no? That's the only place I can recall seeing n with dot above. I suspect that no one at Adobe has ever tested anything related to this area, so you're more likely to find bugs. Is it just Minion where this happens? Hmmm... even in Word, n + combining dot above looks wrong. I suspect it's an issue with the font, not with InDesign. You may need to pick a different font - I think that there are some URW fonts that have been released for free public use for Sanskrit-transliteration stuff.
Thanks Joel and all!
Joel Cherney wrote:
It crashes if you use Optical kerning. It looks ugly! if you use Optical kerning. Don't use optical kerning!
However, I would suggest this not as a policy, but as a troubleshooting technique. If your hangs and/or crashes stop happening as a result of forbidding optical kerning in your workflow, then at that point it can become a policy, and hopefully a bug report to Adobe as well.
Indesign hangs or crashes only when using Optical kerning in XML-workflow. Anyway, I will report to Adobe with evidences/materials. But, I am not sure how to report?
Joel Cherney wrote:
Finally - so, you're doing Sanskrit transliterations, no? That's the only place I can recall seeing n with dot above. I suspect that no one at Adobe has ever tested anything related to this area, so you're more likely to find bugs. Is it just Minion where this happens? Hmmm... even in Word, n + combining dot above looks wrong. I suspect it's an issue with the font, not with InDesign. You may need to pick a different font - I think that there are some URW fonts that have been released for free public use for Sanskrit-transliteration stuff.
We, of course, typeset Sanskrit, Greek kind of books. As in the screen shot attached in one of my above replies, the variations are not only with Minion. I mean I am not complaining about font or Adobe in this case. But, I was only pointing the variations in the characters kerning of the same font (n and above dot) when in Optical and Metrics.
Hope I am not confusing.
Well, as I'm sure you already know, metric kerning means "the font designer decided that glyph x and glyph y should be separated by thus-and-so distance." Optical kerning means "InDesign's font rendering tech is using an algorithm on the curves in the font file and generating what might be an optimal distance." Of course, there are quite a few ways for those curves to be stored in a font, and I've noticed that different font foundries use different techniques that work better with different font rendering techniques. I.e. Adobe fonts don't always play nice in Word, and generic MS fonts often drop when texts using them are placed in ID. I do a lot of Vietnamese typesetting, and combining accents can make my life quite difficult sometimes.
I believe that the cause of the variation you see between metric and optical kerning has to do with how the font is made, and how it gets rendered by ID. The team that makes Minion is not the team that makes InDesign, so I guess you are seeing a failure of Adobe upper management to make sure that the work of team x functions well with the work of team y. There are some kinds of InDesign work (academic work requiring really good footnotes, typesetting languages that aren't Western European or Japanese, database-driven XML workflows) where we see those failures more often, because there are fewer of us, and so Adobe does less quality assurance work on our tools, and there are fewer of us to file bug reports. A bug report submitted to that link will not get any response - if you want to hear back from Adobe "Yes this is a bug, we'll work on fixing it" then you'd need to file a support case.
And I think that the only place where you might be confusing is: I am more-or-less sure you are not asking a question, you are making an observation. If I'm wrong let me know ![]()
North America
Europe, Middle East and Africa
Asia Pacific