The OpenType Layout mechanism is based on "glyph runs". First, the text engine separates a line into glyph runs, and then applies features to each run as if it were separate (i.e. there cannot be any feature interaction between the runs).
The tricky part is that every layout engine has a different mechanism for separating the line into the runs. Of course a switch of the font, or font size, always defines a run boundary. Most layout engines treat the change of text directionality as a glyph run boundary. But they all may differ in how they process characters that do not have a strong directionality. So if you mix Arabic and English, and put a period or a number between a portion of English and Arabic text, different layout engines may classify the period or a number as belonging to one or the other of the adjacent runs, or even to a separate run. Same happens with other punctuation characters. If you type in an Arabic letter, a slash (/) and an English letter, and if the font has GPOS kerning pairs defined between the Arabic letter and the slash, and between the slash and the English letter, either one of those pairs or even both will not work. In addition -- and here the difference is even larger -- layout engines treat the space character very differently. Some applications add an extra space glyph at the end of the line (for example InDesign), so certain contextual rules won't work. Some do and some don't render the space glyph that is used in the font. For example, XeTeX doesn't. If the space glyph is non-blank, it will render in Word but not in XeTeX. In other words, XeTeX puts a run boundary at the beginning and the end of each word, so no OpenType Layout lookups that involve the space glyph will work. Best, Adam -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
