Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f0TMYP709565 for ; Mon, 29 Jan 2001 23:34:25 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f0TMZB724367 . for ; Mon, 29 Jan 2001 23:35:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08A43.A1E5AE80" Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f0TMYJM27479 for ; Mon, 29 Jan 2001 23:34:19 +0100 (MET) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id XAA12687 for ; Mon, 29 Jan 2001 23:34:19 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f0TMYJ701628 for ; Mon, 29 Jan 2001 23:34:19 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <14.753023A8@mail.listserv.gmd.de>; Mon, 29 Jan 2001 23:34:16 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 484973 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 29 Jan 2001 23:34:15 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id XAA14438 for ; Mon, 29 Jan 2001 23:34:14 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id XAA41030 for ; Mon, 29 Jan 2001 23:34:14 +0100 Received: from csc.albany.edu (sarah.albany.edu [169.226.1.103]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f0TMYEY10667 for ; Mon, 29 Jan 2001 23:34:14 +0100 (MET) Received: from pluto.math.albany.edu (pluto.math.albany.edu [169.226.23.44]) by csc.albany.edu (8.9.3/8.9.3) with ESMTP id RAA14198 for ; Mon, 29 Jan 2001 17:34:01 -0500 (EST) Received: (from hammond@localhost) by pluto.math.albany.edu (8.9.3/8.9.3) id RAA14964 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Mon, 29 Jan 2001 17:34:00 -0500 (EST) Return-Path: Content-class: urn:content-classes:message Subject: Re: default font encoding Date: Mon, 29 Jan 2001 23:34:00 +0100 Message-ID: <200101292234.RAA14964@pluto.math.albany.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "William F. Hammond" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3661 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08A43.A1E5AE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank -- 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 of it. 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 emergency recourse. 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 character sets. 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. -- Bill ------_=_NextPart_001_01C08A43.A1E5AE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default font encoding

Frank --

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
of it.

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
emergency recourse.

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
character sets.

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.

          &nbs= p;            = ;            = -- Bill

------_=_NextPart_001_01C08A43.A1E5AE80--