I don't know if you are aware of some private correspondence that I've
had with others. But most who read this list were certainly not part
I think that switching the default font encoding to T1 is probably a
good thing to do.
I hope then that by default there are supported names like
\textgreater \textasciitilde, etc. for all 33 non-alphanumeric
printable ascii characters including 0x20 that work properly in
various LaTeX contexts.
My point of view is that of one writing a formatter from an XML
document type to LaTeX source. Of course, David's Carlisle's xmltex,
which I like as far as I've gone with it, can be used for this, but
it's not the path I began in the summer of 1998, and I still see
reason for formatting to LaTeX source in a system with modular design
since then users (but not this user who just won't do that) have
In the general context of formatting from XML to LaTeX source, though
not so much in my specific context, nor in the context of authors coming
from a LaTeX or TeX background, I am concerned about what happens with
8 bit characters in the range 0xA0 - 0xFF from the various ISO 8 bit
When such characters appear outside of markup in XML they have the
same status as printable alphanumeric ascii characters. Presently one
needs to fight the design of XML systems to accommodate them in
formatting to LaTeX source for use with a default LaTeX installation.
By default with T1, I believe, the input encoding for these characters
matches the "cork" encoding. But when inputenc is set to something
with a standard public name -- for example an 8 bit name that would be
recognized by one of James Clark's XML parsers "xp" or "SP" I think it
highly desirable that the typeset appearance of the characters match
what *should* be the screen appearance in a web browser when the
character set is properly specified.
In particular under such an encoding absent an explicit author
indication for math there should be no math. For example, the
miniature "1/2" at data point 0xBD in ISO-8859-1 (Latin 1) should
*not* be regarded as math unless an author should choose for some
reason I do not anticipate to place it inside math.
(Probably, however, the present inputenc name "latin1" needs to remain
as it is for backward compatibility.)
I believe that David's xmltex accommodates all 16 bit characters under
unicode, but it cannot be used in formatting to LaTeX source.