LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Marcel Oliver <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Fri, 9 Feb 2001 22:10:30 +0100
text/plain (87 lines)

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

- 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

  * 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
    and autoload the necessary packages, to make clear that these
    attributes function orthogonally to each other and to "ordinary"

- 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,