Re: Re: A Standard fallback characters (was: Draft Proposal to add VariationÚ Sequences for Latin and Cyrillic letters)

From: Asmus Freytag (
Date: Wed Aug 04 2010 - 18:04:36 CDT

  • Next message: Kenneth Whistler: "Re: Signage"


    Text typeset in Fraktur contains more information than text typset in
    Antiqua. That means, there are some places where there are some (mild)
    ambiguities in representation in the Antiqua version. Not enough to
    bother a human reader who can use deep context to read the text
    correctly, but enough so that a mere typesetting system cannot correctly
    render such a text in Fraktur.

    I'm not currently aware of anything that would prevent an automated
    system from converting a text encoded for Fraktur to one encoded for
    Antiqua, because you are merely throwing away information.

    So far we agree.

    The question is whether it would be possible to make this process work
    "by default" in common, unmodified rendering engines, and whether that
    is desirable. (I don't treat either of these question as settled one way
    or the other - so please don't attribute a position to me on that subject).

    What I do know is that there are historic documents using Antiqua fonts
    that do use the long "s". Therefore, in principle, you don't necessarily
    want to create fonts that map long to round s. And, as an author, you
    can't rely on such a font being present on the reader's end - it might
    equally likely be one that does implement the long s.

    So, whatever automatic rendering of Fraktur-ready text with non-Fraktur
    general purpose fonts you have in mind, should not rely on this kind of
    non-standard glyph substitution. That would be a terrible hack,
    imperiling the ability of people to use the long s outside the context
    of the Fraktur tradition.

    All I had argued for was that Karl should take out the consideration of
    rendering text encoded for Fraktur from his proposal and make it part of
    a separate document that addresses ALL issues of this type of rendering,
    making it a complete specification - that would be something that allows
    review on its own merits.


    This archive was generated by hypermail 2.1.5 : Wed Aug 04 2010 - 18:06:03 CDT