Re: logos, symbols, and ligatures

From: Otto Stolz (
Date: Mon Nov 05 2007 - 13:16:52 CST

  • Next message: Werner LEMBERG: "Re: logos, symbols, and ligatures"


    Jeroen Ruigrok van der Werven had written:
    > German is like Dutch, for all I know, in the ways you hyphenate words
    > (typically on a syllable basis). And the way you hyphenate determines
    > whether or not you can use ligatures or not. So I have to agree with
    > Werner here, the syllable boundary stops the ligature formation.

    Philippe Verday has written:
    > Not really. The syllable boundary stops ONLY SOME ligature formations.
    > In fact, the rule that determines if syllable break are disallowed is based
    > on radicals, not on syllables: in a compound word, it doesnot matter if a
    > radical is multisyllabic, as ligatures are permitted everywhere in the
    > radical, but not across a radial boundary.

    True. (I prefer to call those radicals "constituents".) However,
    I have made a habit of providing hyphenating-points on data-
    entry, for the constituent boundaries only. This will render
    hyphenation much more pleasant, and much less misleading. E. g.,
    I'd enter the word »Radiosendung« as »Radio·sendung« (where »·«
    is the hyphenation-opportunity incantation of my word processor),
    in order to avoid the unpleasant hyphenation of »Radiosen-
    dung« (I guess, you don't need to know German to understand the
    problem, as it manifests itself likewise to the English reader.)
    This will provide enough leeward room for the word-processor to
    generate a satisfactory paragraf layout: normally, there is no
    need to hyphenate between syllables within a constituent.

    In some cases, the hyphenation between constituents is even mandatory.
    E. g. »Druck·erzeugnis« and »Drucker·zeugnis« have quite different
    meanings. (In those cases, you may provide a real hyphen in the
    soft-hyphen's stead, in order to avoid misunderstandings.)

    > It does not prevent for example the "ff" ligature, because the two
    > letters are (almost) always occurring over a syllable break (except
    > at end of a word). The "ff" ligature is an example where ligation
    > occurs for aesthetical reasons.

    Wrong (for German). Rather, »ff« obeys the same rules. E. g.,
    »auf·fliegen« has an fl-ligature (in professional typography),
    while it must not have an ff-, nor an ffl-ligature (in any
    typography that claims to be orthographically correct).

    > * the ess-tsett, for example, is a ligature that obeys additional
    > constraints, where syllable breaks are still significant, and not just the
    > radical break; for this reason, no ess-tsett is allowed in the verb
    > "müssen", despite there's only one radical (but two syllables), but it is
    > preferred in the "muss" conjugated form

    This is entirely wrong.

    »ß« is perceived as a single letter (though it stems from a ligature).

    In contemporary orthography, »ss« (if not belonging to different
    constituents) marks the preceding vowel short (as any consonant
    doubling does), whilst »ß« marks the preceding vowel long. So its
    both »müssen«, »muss«, and »musste«, because the »ü«, or »u«, re-
    spectively, is short. In contrast, it is »Fuß«, and »Füße«, because
    the the »ü«, or »u«, respectively, is long. Btw, it is »Rose«,
    because the »s« is voiced.

    Between 1901 and 1996, an additional rule changed the »ss« into »ß«
    before consonants, and at the end of a constituent. Hence, it was
    »müssen«, »muß«, and »mußte«, then. Also »Paßamt«, because this is
    a compound of »Paß« (now: »Pass«) and »Amt«.

    > in "Straffen", the "ff" ligature is permitted, because there's only one
    > radical, even if there are two syllables.

    Right, but this rule pertains to any ligature.

    > there's no compound word in German where a
    > single final "f" of a radical is followed by another "f" from the initial of
    > the next radical

    »Hof·fläche«, »auf·fahren«, »Schief·füßer« (the latter is somewhat artificial), ...

    > In other words, the set of rules for allowing or forbidding a ligature is
    > not only specific to each language, but also within each language, specific
    > to each ligature.

    Not so for German.

    > That's why I don't think a any general purpose renderer
    > can appropriately infer the presence or absence of ligatures: this requires
    > the help of language identification, knowledge of the language-specific
    > radicals and allowed mutations and suffixes used for derived forms.

    > This job is part of a spellchecker, that must help the renderer by inserting
    > ligature hints (ZWJ) or using a dedicated character (the "ae letter" in
    > Unicode is a ligature in some languages) everywhere ligatures are permitted
    > (and preferable or sometimes mandatory).

    And a spell-checker may well be overstrained, as demonstrated by the
    minimal pair, supra. Hence, the author should provide hints, at least
    for German, where you can come up with any compound you can fancy.

    > A renderer alone should NOT take the decision of creating a ligature

    What about the mandatory ligatures in Fraktur (blackletter)?

    Personally, I'd be happy with a word-processor that introduces
    ZWNJs at the author-supplied hyphenation points, and a renderer
    that takes the opportunity of using a ligature where one is
    available in the font at hand (and, of course, where there is
    no ZWNJ).

    As an author, I can easily signal where no ligature must occur
    (and I do it anyway, to allow for sensible hyphenation, as discussed
    supra). But I never can foresee, which letter-pairs might form a
    ligature in any of the fonts my text may end to be rendered with.
    Imagine the headache Philippe's proposition would cause authors,
    and printers: You'd have to manually change the encoding of your
    text, whenever you choose another font for rendering - just to cope
    with the letter-forms that may demand a particular ligature.

    Best wishes,
       Otto Stolz

    This archive was generated by hypermail 2.1.5 : Mon Nov 05 2007 - 13:19:00 CST