## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

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

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