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 f19LGFH05822 for ; Fri, 9 Feb 2001 22:16:15 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f19LGFd19245 . for ; Fri, 9 Feb 2001 22:16:15 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f19LGE725863 for ; Fri, 9 Feb 2001 22:16:14 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C092DD.88FBB980" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id WAA13791 for ; Fri, 9 Feb 2001 22:16:14 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f19LGCM12610 for ; Fri, 9 Feb 2001 22:16:13 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <8.5C3DCBFD@mail.listserv.gmd.de>; Fri, 9 Feb 2001 22:16:06 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 489165 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 9 Feb 2001 22:10:38 +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 WAA28509 for ; Fri, 9 Feb 2001 22:10:37 +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 WAA22268 for ; Fri, 9 Feb 2001 22:10:37 +0100 Received: from naf1.mathematik.uni-tuebingen.de (naf1.mathematik.uni-tuebingen.de [134.2.161.197]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f19LAbu29134 for ; Fri, 9 Feb 2001 22:10:37 +0100 (MET) Received: from na13.mathematik.uni-tuebingen.de (na13 [134.2.161.180]) by naf1.mathematik.uni-tuebingen.de (8.9.3+Sun/8.9.3) with ESMTP id WAA11813; Fri, 9 Feb 2001 22:10:31 +0100 (MET) Received: (from oliver@localhost) by na13.mathematik.uni-tuebingen.de (8.9.3+Sun/8.9.1) id WAA24882; Fri, 9 Feb 2001 22:10:30 +0100 (MET) In-Reply-To: <200102091643.RAA23818@mozart.ujf-grenoble.Fr> References: <200102091445.JAA00482@plmsc.psu.edu> <200102091643.RAA23818@mozart.ujf-grenoble.Fr> Return-Path: X-Mailer: VM 6.88 under Emacs 20.7.2 X-Authentication-Warning: na13.mathematik.uni-tuebingen.de: oliver set sender to oliver@na13 using -f Content-class: urn:content-classes:message Subject: Re: inputenc text (and/or math) Date: Fri, 9 Feb 2001 22:10:30 +0100 Message-ID: <14980.23750.628032.305093@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Marcel Oliver" 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: 3788 This is a multi-part message in MIME format. ------_=_NextPart_001_01C092DD.88FBB980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, some thoughts about the current discussion on input/font encoding issues (sorry for not quoting all your mails, there are just too many). Some have come up in some form or other, so if I repeat anything, it's because I think it's important... - I believe the only reasonable default _input encoding_ is UTF8. Being a superset of ASCII while covering all of unicode, it seems the ideal long-time solution to all input-encoding related problems. UTF8 is also becoming rather well supported by editors and other applications. - In particular, defaulting to any other 8-bit input encoding in LaTeX2e should be avoided at all cost because it would really mess up the upgrade path to UTF8 later. (As far as I understand, the proposed default of \usepackage[T1]{fontenc} does not default any 8bit input encoding. Is this correct?) - A regular user should never have to specify the _font encoding_. There should only be language environments (as provided by babel) and font packages (e.g. times, palatino). This means: * Babel (or something providing equivalent functionality---I strongly believe that it should become part core LaTeX3) must be endowed with a default set of fonts for all languages it supports. Some language environment defaults could be marked experimental, meaning that associated fonts and TFMs may change once better quality free fonts become available, but all languages must work "out of the box". One the other hand, languages like german for which the EC fonts are well accepted (?), could be frozen straigt away. * The language environment chooses the default font encoding unless a font package is explicitly loaded. There may be more than one language environment per language if different typographical esthetics need to be satisfied. * Babel must hook into the currently active font package. If a language environment is selected, the font package must be called to set itself up. In other words, every font package must make a decision about encoding as a function of the language selected. If the language is unknown to the font package, a warning or an error must be issued. (I am sure the set of supported language-font pairs will grow quickly if a good mechanism for soliciting contributions is implemented.) * Maybe one can introduce commands like \uselanguage{spanish} \usefont{times} and autoload the necessary packages, to make clear that these attributes function orthogonally to each other and to "ordinary" packages. - Is there really a need for breaking the distinction of math mode vs. non-math mode? As far as Greek letters go, the most common one is $\mu$ in units. This raises the question if one should not provide standard markup for units anyway (some journal packages are doing it---there are also spacing issues involved that warrant special treatment), for example as a "tools" package in the standard LaTeX distribution. Further, the $\mu$ in units which are usually set in upright shape should presumably be different from the $\mu$ in math which goes with italic shape letters. All other uses I can think of are either clearly math, or clearly Greek, so it seems more important to make Greek as such work "out of the box". - Hyphenation tables should really be Unicode (so possibly UTF8 encoded). They are logically neither input nor output encoding related, and should work regardless whether either refers to a castrated font set. - For special needs, such as easy typing of cyrillic math in 7bit ASCII one could provide special input encodings. In full unicode this shouldn't be a problem, should it? I am aware that some of these demands cannot really be met within Knuthian TeX, but it seems LaTeX3 is prepared to eventually go beyond TeX. So it may be useful to define a minimal set of required extensions/changes, as this issue could be a major roadblock to enlarging the developer base. For example, is there much motivation for anybody to clean up the hyphenation mess before a clean long-term solution (not just a work-around) is agreed on? Just some ideas, Marcel ------_=_NextPart_001_01C092DD.88FBB980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc text (and/or math)

Hi,

some thoughts about the current discussion on = input/font encoding
issues (sorry for not quoting all your mails, there = are just too
many).  Some have come up in some form or other, = so if I repeat
anything, it's because I think it's = important...

- I believe the only reasonable default _input = encoding_ is UTF8.
  Being a superset of ASCII while covering all = of unicode, it seems
  the ideal long-time solution to all = input-encoding related problems.
  UTF8 is also becoming rather well supported by = editors and other
  applications.

- In particular, defaulting to any other 8-bit input = encoding in
  LaTeX2e should be avoided at all cost because = it would really mess
  up the upgrade path to UTF8 later.  (As = far as I understand, the
  proposed default of \usepackage[T1]{fontenc} = does not default any
  8bit input encoding.  Is this = correct?)

- A regular user should never have to specify the = _font encoding_.
  There should only be language environments (as = provided by babel)
  and font packages (e.g. times, = palatino).  This means:

  * Babel (or something providing equivalent = functionality---I
    strongly believe that it should = become part core LaTeX3) must be
    endowed with a default set of = fonts for all languages it supports.
    Some language environment defaults = could be marked experimental,
    meaning that associated fonts and = TFMs may change once better
    quality free fonts become = available, but all languages must work
    "out of the box".  = One the other hand, languages like german for
    which the EC fonts are well = accepted (?), could be frozen straigt
    away.

  * The language environment chooses the default = font encoding unless
    a font package is explicitly = loaded.  There may be more than one
    language environment per language = if different typographical
    esthetics need to be = satisfied.

  * Babel must hook into the currently active = font package.  If a
    language environment is selected, = the font package must be called
    to set itself up.  In other = words, every font package must make a
    decision about encoding as a = function of the language selected.
    If the language is unknown to the = font package, a warning or an
    error must be issued.  (I am = sure the set of supported
    language-font pairs will grow = quickly if a good mechanism for
    soliciting contributions is = implemented.)

  * Maybe one can introduce commands like
      = \uselanguage{spanish}
      \usefont{times}
    and autoload the necessary = packages, to make clear that these
    attributes function orthogonally = to each other and to "ordinary"
    packages.

- Is there really a need for breaking the distinction = of math mode
  vs. non-math mode?  As far as Greek = letters go, the most common one
  is $\mu$ in units.  This raises the = question if one should not
  provide standard markup for units anyway (some = journal packages are
  doing it---there are also spacing issues = involved that warrant
  special treatment), for example as a = "tools" package in the standard
  LaTeX distribution.  Further, the $\mu$ = in units which are usually
  set in upright shape should presumably be = different from the $\mu$
  in math which goes with italic shape = letters.  All other uses I can
  think of are either clearly math, or clearly = Greek, so it seems more
  important to make Greek as such work "out = of the box".

- Hyphenation tables should really be Unicode (so = possibly UTF8
  encoded).  They are logically neither = input nor output encoding
  related, and should work regardless whether = either refers to a
  castrated font set.

- For special needs, such as easy typing of cyrillic = math in 7bit
  ASCII one could provide special input = encodings.  In full unicode
  this shouldn't be a problem, should it?

I am aware that some of these demands cannot really be = met within
Knuthian TeX, but it seems LaTeX3 is prepared to = eventually go beyond
TeX.  So it may be useful to define a minimal = set of required
extensions/changes, as this issue could be a major = roadblock to
enlarging the developer base.  For example, is = there much motivation
for anybody to clean up the hyphenation mess before a = clean long-term
solution (not just a work-around) is agreed = on?

Just some ideas,

Marcel

------_=_NextPart_001_01C092DD.88FBB980--