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

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: inputenc text (and/or math)

From:

Date:

Fri, 9 Feb 2001 22:10:30 +0100

Content-Type:

text/plain

Parts/Attachments:

 text/plain (86 lines)
 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