From: John Hudson (john@tiro.ca)
Date: Fri May 04 2007 - 14:30:52 CST
Marnen Laibow-Koser wrote:
> It is a character, I think. To assume that it is an uppercase SS
> ligature is to assume that an uppercase long S exists -- and we have
> absolutely *no* evidence for that at all. So I think it's begging the
> question to assume that it is a ligature. Uppercase ß is attested, if
> grudgingly so. Uppercase long s is not attested at all!
I am not assuming that it is a ligature: I am questioning the assumption that it is a
character *in the text processing use of these terms*.
First I must correct what is a common misconception of 'ligature': a ligature in text
processing terms is a single glyph that represents more than one character. This does not
imply anything at all about the visual form that ligature takes or its visual relationship
to the underlying characters. You are claiming that the uppercase eszett is not a ligature
because it looks like a combination of a long s with some other form, and there is no
uppercase long s. This is completely irrelevant to the counter proposal that I put
forward, which is that the uppercase eszett is a glyph variant ligature representation of
the orthographically normal SS uppercase encoding of ß. Why would it be anything else?
There are plenty of similar cases in the Unicode universe of languages within which the
preferred display of a digraph is ligated in some way, and these are not considered
separate characters or requiring a character-level solution to their display requirements.
The proposal for the uppercase eszett is explicit that this is a display requirement: it
is a way of representing in text a particular symbol that has been used in some places by
some people as a substitute for SS in all caps settings of words containing ß. So my
response is that we should first examine how this display requirement might be handled at
the diplay level, i.e. at the glyph processing level, rather than assuming that the answer
is to encode this glyph.
Another way to look at this is to consider that the claim of character status for this
glyph is based on the necessity of excluding this glyph from all normal German text
processing, i.e. from a casing relationship to the lowercase ß. But this necessity is
itself a product of the assumption that it is not a ligature, i.e. it must be excluded
precisely because it is assumed to be a character that would otherwise cause havoc for
German text processing standards and software. But I have proposed a means by why a plain
text distinction can be maintained while no affecting existing German text implementations
and providing lossless font switching between older fonts that do not support the glyph
and new ones that do. And this is possible by treating the uppercase eszett as a ligature
-- in the text processing sense -- of <S ZWJ S> and not of <S S>. Why introduce a new
character that will cause text interchange and display problems for large numbers of users
when an existing, backwards compatible mechanism for this sort of thing is already defined
within Unicode?
John Hudson
-- Tiro Typeworks www.tiro.com Gulf Islands, BC tiro@tiro.com We say our understanding measures how things are, and likewise our perception, since that is how we find our way around, but in fact these do not measure. They are measured. -- Aristotle, Metaphysics
This archive was generated by hypermail 2.1.5 : Fri May 04 2007 - 14:32:05 CST