Re: Latin ligatures and Unicode

From: Mark E. Davis (markdavis@ispchannel.com)
Date: Mon Dec 27 1999 - 12:09:11 EST


There is a lot of confusion around this subject. For example, in this
case

>1. As I pointed out in my reply to John Jenkins, there are cases where
the software will not be able to determine ligation correctly. (The
"Wachstube" example)
TRUE
> In these cases the author MUST explicitly specify ligation.
TRUE
> So Unicode MUST provide means to do so, eather by defining ZWJ or ZWL
to be the character that specifies ligation behaviour in latin scripts.
FALSE

It is a big jump to say that because ligation must be controlled, to the
conclusion that a new character is required to control it. As I've said
before on this topic, there are different ways to control ligation: an
explicit character, or a GUI (as italic is specified). Take the above
argument with regard to italic

*1. As I pointed out in my reply to John Jenkins, there are cases where
the software will not be able to determine ITALICS correctly. E.g.
"<i>Did</i> you do it?" vs. "Did <i>you</i> do it?" vs "Did you do
<i>it</i>?"
TRUE
[There are many cases where meaning is lost if the italics are
discarded; probably many more cases than the few cases cited where the
loss of ligatures loses meaning.]

* In these cases the author MUST explicitly specify ITALICS.
TRUE

* So Unicode MUST provide means to do so, by defining ZWI to be the
character that specifies ITALIC behaviour in latin scripts.
FALSE
No, because there are other mechanisms to do this, by carrying style
information or markup with the text.

While we may end up accepting format characters that turn ligatures on
or off, the issue is just not a clear-cut as it is made out to be.

Mark

Eberhard Pehlemann wrote:

> peter_constable@sil.org schrieb:
>
>> If software can automatically do something in one place, it
>> seems to me that it should also be able to do an equivalent
>> thing in another place. I.e. if software can automatically
>> add
>> ZWL at appropriate places to create the desired ligature
>> glyphs
>> on output, then software should also be able to automatically
>>
>> select the desired sequences of character codes (sans ZWL) to
>>
>> substitute by ligature glyphs. At least, that seems to make
>> sense to me unless there's more to this story than I'm not
>> aware of.
>>
>> For unpredictable ligatures, it should be possible (i.e. 'it
>> is
>> technologically feasible', not 'software ought to be able')
>> to
>> apply style information to the relevant run of text enabling
>> a
>> feature that causes ligation.
>
> I agree that software could (and should) do a lot concerning ligatures
> in the latin script.
>
> But from my point-of-view there are several arguments against letting
> the software do everything (and preventing explicit specification of
> ligation behaviour by the author):
>
> 1. As I pointed out in my reply to John Jenkins, there are cases where
> the software will not be able to determine ligation correctly. (The
> "Wachstube" example) In these cases the author MUST explicitly specify
> ligation. So Unicode MUST provide means to do so, eather by defining
> ZWJ or ZWL to be the character that specifies ligation behaviour in
> latin scripts. I agree with Micheal Everson who has claimed the need
> for such a character.
>
> 2. Software can do a lot, but does it do so? I am pretty sure that
> there does not exist a single text editor that handles all blackletter
> ligatures. But even in the much more common case of roman fonts and
> the fi, ffi, ffl … ligatures: How many programs actually use ligature
> shapes to display these character sequences? And how much money do
> they cost?
>
> 3. With the OpenType or related fonts every font designer can offer
> ligature shapes in his fonts. I would like to do so for the (few?)
> people that like blackletter fonts. If there was a ZWJ or an official
> declaration that Unicode ZWJ and ZWNJ should be used to force or
> prohibit ligation in latin scripts, then every writer could use the
> ligature shapes offerd by the fonts. He would need only basic software
> abilities built-in to the operating system and thus also accessible
> from small and affordable applications. He would not need to by
> Indesign and then see that he gets fi ligatures but doesn't get others
> like sch, tz or ft in Fraktur.
>
> 4. What about portability and exchangeability of text fragments, if
> one program handles ligatures and another does not? Should we forget
> copy and paste, because ligation information simply gets lost when
> pasting from one application to another? ZWJ ore ZWL would certainly
> not get lost in this process!
>
> Although my knowledge is limited to the blackletter case which is a
> historical one and thus probably has low priority for the experts
> developing Unicode, I have learned from the contributions of Micheal
> Everson and others that the arguments listed above will apply
> similarly to other and more common cases.
>
> The discussion which arose from my first mail is still going on. I
> feel that the problem of ligatures in the latin script is not yet
> solved. I think that it should be solved inside Unicode by defining
> control characters that explicitly define ligation behavior. These
> controls then could be used in conjunction with OpenType font tables
> to provide an almost application-independent means of controlling
> ligature display. The experts have to decide whether ZWJ and ZWNJ
> should be used for this purpose or not, and if there also is a need
> for a ZWNL in addition to a ZWL character. Clear statements on what
> theses characters are made for in latin script should accompany these
> decisions.
>
> Maybe, ligation in the arabic and indic scripts has been a problem
> more urgent to be solved by Unicode than ligation in the latin script.
> But now the time has come to find a solution to the latter, too!
>
> Sincerely, Eberhard
>
> -------------------
> --------------------------------------------------------------------------------------
>
> Eberhard Pehlemann, Dorfstraße 7, D-23909 Giesensdorf, Germany, Tel.
> +49 4541 858102
>



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:57 EDT