At 12:22 PM 7/17/02 -0500, Peter_Constable@sil.org wrote:
>On 07/09/2002 03:20:22 AM Asmus Freytag wrote:
>[I'm coming late into the discussion; apologies if this ground has already
> >OK. Here we go again. There is simply no way that one can
> >ligate standard German without text (!) based control...
>I wonder if language/writing system-dependent control isn't appropriate in
>the case of German as well as, e.g., Turkish. For instance, in an OT font,
>have default lookups to form ligatures, and then have rules specific to
>German, just as one would for Turkish, that do not form liguatures by
>default. In the case of Turkish, the reason for the default being not to
>form ligatures has to do with the use of both dotted and dotless i. In the
>case of German, the reason is different: it's not done by default since it
>isn't appropriate for it to be done everywhere, and the contexts in which
>it is appropriate can't realistically be captured in a font.
Good. That's the key point.
> The German
>support in the font could still include the rlig lookups John has
>suggested; and an intelligent app might even activate ligatures
>automatically (like the SHY analogy Asmus mentioned) either by setting an
>appropriate feature over the appropriate contexts or by inserting ZWJ into
>strings at rendering time.
German has default ligatures that are *prohbited* at certain locations, but
fine for all other instances. Therefore, using zw*N*j works fine out of the
box - as long as the rendering system renders it invisibly. <f , zwnj , i>
should never ligate anyway, even with current fonts, so any rendering
system that passes the zwnj to a font, gets the glyph for it (and therefore
gets the normal glyphs for f and i as a result, not the ligature for <f ,
i>) and then ignores the glyph for the zwnj would work fine. [If the
renderer removes the zwnj from the string before glyph lookup, the result
will be an unintended ligature, of course].
Anyway, it's the *non*-joiner, not the joiner we are talking about here.
This archive was generated by hypermail 2.1.2 : Wed Jul 17 2002 - 23:26:07 EDT