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./



Reply via email to