From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Wed Aug 04 2010 - 18:04:36 CDT
Philipe,
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.
A./
This archive was generated by hypermail 2.1.5 : Wed Aug 04 2010 - 18:06:03 CDT