On Tue, 15 Feb 2011, Jonathan Kew wrote: > Yes, you can't do lookups that involve <space>, because of how xetex > handles word spacing.
If it doesn't work in XeTeX, there will probably be other applications in which it also doesn't work - so changing XeTeX wouldn't solve the problem. In general, I think it's a bad idea to try to write features that depend on a <space> glyph; spaces really are not glyphs, and it's reasonable that an application won't pass them to the font. The Adobe specification does discuss word boundary detection here: http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#5.f.ii They use an "ignore" rule to block substitution when the search string is preceded by a letter glyph. So instead of saying "substitute only when preceded by a space" it means "substitute always, except when preceded by a letter". At the start of a word, there is no preceding glyph, so the ignore doesn't match and the main rule does match. Of course, something similar could be done at the end of a word. This approach seems more reliable than asking the application to pass in a space glyph for the rule to detect. The document linked above also mentions a possiblity of limiting an entire feature (all rules in the feature) to match only at the start or end of word, using a "feature tag registry" entry. I'm not sure how one does that in practice, or whether it may be a hardcoded thing associated with the four-letter name of the feature. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex