by Michael S. Kaplan, published on 2008/05/04 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/05/04/8457270.aspx
Over in the Suggestion Box, AJB asked:
I am curious about the division of labor between Uniscribe (or any other rendering\layout engine) and the OpenType font, with regards to glyph substitution.
I've been poking around parsing the OpenType font data for Tahoma.ttf. It has a GSUB section for Arabic, with features for initial, median, and final forms. From reading the OpenType spec, I guess I would have expected the font to use contextual substitution: eg if the character before is one of X, and the current character is one of Y, replace the current character with the final form (or whatever). Instead, the font just has simple substitution tables: the 'fina' feature has a list of glyphs that are replaced by a separate list of glyphs.
Does that mean the brains is in Uniscribe? Does Uniscribe take the rules of Arabic, decide that a character is in the final position, then search out the 'final' feature to see what glyph to substitute? What is the dividing line between the responsibility of the rendering engine and the font itself?
Thanks,
ajb
This one is of course a little bit outside my areas of expertise, since I am much more a fan of good typography than someone who could actual create beautiful fonts for any language or script, though I'll see if I can say a few words on the subject. :-)
A lot of the logic and planning behind OpenType typography is more art than science, and there really is more than one way to do the job here. For example, looking at arabtype.volt.ttf (a file that comes with VOLT):
Let's take a look at the init, medi, fina, abeautifulnd isol tables for a moment:
Some of them are totally obvious -- like the ones that map to compatibility range glyphs that match the ones shown here.
Kind of implies that everything I said about the compatibility ranges in It Does Not Always Pay to be Compatible and Getting out of dodge (or at least out of the compatibility range!) and Getting out of the compatibility zone, redux doesn't apply to typographers, right? :-)
But if you look at these mappings carefully (and especially if you compare the glyphs here to the ones that show up in Character Map, you;ll see that sometimes the glyphs don't match because further mapping happens later.
And this gets to the heart of why you would want to avoid those compatibility range letters -- because you will miss out on any of the other additional mapping that is done as a matter of course.
Plus in the file there are optional forms for sinhi and Urdu and all kinds other information as well -- information that Uniscribe can use to decide what to do here.
To get back to AJB's original question, just because a font provides all of this information in the tables does not mean that one couldn't use another means of doing the same thing -- such as contextual substitution. Some of these other substitutions beyond the simple ones in the init, medi, and fina tables are actually contextual substitutions already, and there is no resin that one couldn't do more of that.
Though of course actual typographers can likely give better answers here, and the fact that I hope some of them will do so has just caused me to delete a whole bunch of additional screen shots and table spelunking I was doing....
Typography, in OpenType or otherwise, is as much art as science. OpenType doesn't change that as much as you might imagine....
This blog brought to you by ﴮ (U+fd2e, aka ARABIC LIGATURE SHEEN WITH HAH INITIAL FORM)