From: Asmus Freytag (email@example.com)
Date: Mon Nov 05 2007 - 03:27:55 CST
On 11/4/2007 3:29 PM, Kent Karlsson wrote:
> Adam Twardoch wrote:
>> In German, it is considered correct to only use ligatures within one
>> part of a compound word, but not across the parts. For example, in the
>> same text, you would use the "fl" ligature in the word "fliegen" (to
>> fly) and you would NOT use a ligature in the word "auflegen"
>> (to put on, to lay sth on sth), since it's "auf+legen".
This was true even for the Fraktur style which, unlike the Antiqua style
that replaced it
for modern German did have the concept of *required* ligatures as well.
(And the numbers
of optional ligatures include many that we might rarely encounter in a
The archives of this list give many examples of compound words where the
of the compound elements need to be known to determine the meaning of
the word. As
Adam point out, German orthographic practice (and I use this term
deliberately, even though
the effect is only visible when text is typeset) is to use the presence
of ligatures to mark the
*absence* of such a a boundary. In other words, you never ligate across
such a boundary
as it would mislead the reader.
(Unlike Fraktur, leaving out all ligatures is OK, but in its own way,
perhaps not the best typography).
> (Considering only pure typographic ligatures, not any kind of
> embellishing ligature.)
> Then you would either:
> a) get an ugly overlap for "auflegen" (why accept that?), or
> b) get an ugly extra spacing for "auflegen" (why accept that?), or
> c) there is no need for a ligature anyway, so why force one
> (that is visually distinct from not ligating) for "fliegen", or
> d) need to use a special f glyph to avoid the overlap (and that
> would technically be a ligature, though actually separating
> the glyphs), which is unlikely to be aesthetically pleasing.
> Could you elaborate please.
Technology should exist to support the way people write, not the other
way around. Given
that, a font that is acceptable for German would look good both when
showing an unconnected
f and l, as well as when showing a ligature - both will be needed.
Creating outlines that fudge
the issue by making overlapping glyphs look (nearly) indistinguishable
from a ligature is
a cute trick for English and other languages, were ligatures are
permissible in any position
in any word, but not ideal for languages like German where that is not
the case, and where
a distinct appearance of ligated and not ligated pairs is desired.
Whether or not you consider the occasional use of separate f and l
something that is
aesthetically pleasing is besides the point: first and foremost it is
correct usage according
to the orthography of the language in question (and is a prescription
that has managed to
survive a rather drastic change in typographical style).
Now, once you've accepted that as a legitimate requirement, as an
implementer you can
start to figure out how to get the aesthetics back into the picture. I'm
not a type designer,
but I sense a certain anglocentricity in the designs that originate with
or are distributed by
large US software houses. So I would be surprised to see that you find
there. Perhaps there are suitable examples from the time of hot metal
you could study.
> B.t.w., if a font has a ligature for <a, ZWJ, e> then that should
> be blocked by the display system, since æ should be achieved only
> by using the dedicated character (as opposed to the fi/fl ligatures).
Having the rendering system enforce Scandinavian orthographic
preference? I think that's
going a bit too far. That belongs not in the rendering system, but in
the spell checker.
> And long s is a separate character, the glyph for which should not
> be produced by a short s.
The use of long and short s, when the long s was still used, in German
follows similar rules
as the ligatures. Use of the short s was required not only for any s at
the end of a word, but
also at the end of an element in a compound word; it is for this and
similar reasons, that the
choice between long s and short s cannot be delegated to the rendering
system or the font.
This archive was generated by hypermail 2.1.5 : Mon Nov 05 2007 - 04:30:18 CST