Re: Uppercase ß is coming? (U+1E9E)

From: John Hudson (
Date: Fri May 04 2007 - 14:30:52 CST

  • Next message: John Hudson: "Re: Uppercase ß is coming? (U+1E9E)"

    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
    Gulf Islands, BC
    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