Le 15/02/2011 11:14, Georg A. Duffner a écrit :
Am 2011-02-15 04:38, schrieb David J. Perry:
I had the exact same problem last weekend. I constructed an OT feature
to replace a long s with a regular s if followed by a comma, period,
space, etc. The longs-space combination did not work. I am not a
low-level TeX programming kind of guy, but I had learned a bit somewhere
about TeX's "glue" and I wondered if the OT parser did not see the space
character. Thanks to Khaled for confirming this.
David
----- Original Message ----- From: "Khaled Hosny"
<[email protected]>
To: "Unicode-based TeX for Mac OS X and other platforms" <[email protected]>
Sent: Monday, February 14, 2011 6:35 PM
Subject: Re: [XeTeX] OT features
On Mon, Feb 14, 2011 at 10:24:14PM +0100, Georg A. Duffner wrote:
For my font project (see www.georgduffner.at/ebgaramond) i have been
playing around with some opentype features. It seems, that
contextual features involving the character "space" don’t work as
expected.
AFAIK, XeTeX processes each word in isolation, so space never part of
context (also in TeX space is not a character/glyph but a kind of a
property named glue, so it does not get handled by OT layout).
Generally speaking, using space in context is fragile and not
guaranteed
to work everywhere.
I wanted to implement a feature for latin texts that
replaces "u" at the beginning of a word by a letter that looks like
"v". The rule looks like this:
'init' feature should be more suitable here, but almost all OT engine
supports it for few selected scripts (Arabic mainly). With 'init' it is
the responsibility of the engine to detect word beginning.
Thanks Khaled,
I already feared such implication being the culprit. In this case, the
solution was simple since it’s easy to reverse the lookup: replace
every "u" by a "v"-like glyph and then make a contextual rule that
changes them to a "u"-like one after a letter. But I don’t think I’m
gonna keep this as default for latin but rather put it in a stylistic
set.
I'm quite new to the internals of OT, but what I've seen implemented in
similar cases looks more like this: keep "u" as is, and make a
contextual rule on it with two lookups: the first is triggered whenever
there's something before the "u", and does nothing; the second is
triggered in any context and changes "u" to "v". If the first applies,
the second doesn't. That's the way word-final variants are implemented
in Minion, except the context of the first lookup is not all glyphs, but
almost all glyphs, excluding for instance punctuation marks. Thinking
about it, this should be the case for you too: the first lookup
shouldn't be triggered by a left parenthesis.
(Sorry if I don't have the terminology right, I've been investigated
fonts for some weeks only.)
Best,
Paul
--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
