[XeTeX] OT features

[Georg A. Duffner]

Am 2011-02-15 11:26, schrieb Paul Isambert:
> 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"
>>> <khaledhosny at eglug.org>
>>> To: "Unicode-based TeX for Mac OS X and other platforms" <xetex at tug.org>
>>> 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
>

Hi Paul,
the solution you suggest should work too, i think. I’ll check tonight.

Best regards,
Georg