X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2638" "Fri" "19" "November" "1999" "11:57:40" "+0100" "Bernard GAULLE" "gaulle@IDRIS.FR" nil "61" "Re: mltex (was: encodings pair, babel 3.7 beta release)" "^Date:" nil nil "11" nil "mltex (was: encodings pair, babel 3.7 beta release)" nil nil nil] nil) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id LAA28710 for ; Fri, 19 Nov 1999 11:58:01 +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 <11.C90AB637@mail.listserv.gmd.de>; Fri, 19 Nov 1999 11:57:58 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 445534 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 19 Nov 1999 11:57:37 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id LAA23289 for ; Fri, 19 Nov 1999 11:57:34 +0100 (MET) Received: from lumiere.idris.fr (lumiere.idris.fr [130.84.8.14]) by relay.uni-heidelberg.de (8.9.1b+Sun/8.9.1) with ESMTP id LAA01018 for ; Fri, 19 Nov 1999 11:57:48 +0100 (MET) Received: from murnau.idris.fr (murnau.idris.fr [130.84.8.20]) by lumiere.idris.fr (8.9.3/8.9.3) with ESMTP id LAA08472 for ; Fri, 19 Nov 1999 11:57:46 +0100 (MET) Received: (from gaulle@localhost) by murnau.idris.fr (8.9.1a/8.9.1) id LAA00355; Fri, 19 Nov 1999 11:57:40 +0100 Message-ID: <199911191057.LAA00355@murnau.idris.fr> Reply-To: Mailing list for the LaTeX3 project Date: Fri, 19 Nov 1999 11:57:40 +0100 From: Bernard GAULLE Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: mltex (was: encodings pair, babel 3.7 beta release) Status: R X-Status: X-Keywords: X-UID: 3431 >>>>> On Wed, 17 Nov 1999 15:27:12 +0100, "Denis B. Roegel" said: > DR> To some extent the same goes with encodings, both input and output. > DR> Given the features of TeX, the choice of the output encoding > DR> is relevant for hyphenation, > > hum, i guess you wanted to say: hyphenation is relevant of the font in use. DR> No, I meant what I wrote. well that wording is inappropriate. We should say: hyphenation depends of the font in use. I wrote: > no, any TeX using mltex option is independent of encodings. You can > use CM, EC, Times, ... what you want with any related encoding. > It would be so easy if all formats around the world were done > with the mltex option. It's free, standard (as an option can be) and > without any danger. But life is different ;=) DR> I meant "the brand of TeX you are using is *usually* not DR> independent of the (font) encoding you use." it should. Only few TeX engines don't accept all font encodings, which ones? DR> Who uses mltex? DR> Some people, but not everybody. so you should come back to Word: everybody use it... In other words i prefer to have plus than minus, but everybody is free to use what he wants. DR> Besides, I haven't followed the latest developments of MlTeX, DR> but it used to be the case that fonts had to have a certain DR> number of free slots for the "fictitious characters" MlTeX DR> creates, in case these \charsubdef is used. no, they are not "reserved" but "used" e.g. any new glyph defined by \charsubdef is associated to a slot in the font, as any other glyph... DR> Is this no longer true? If it is still true, it means DR> that some fonts cannot be used in MlTeX and at the same time DR> remapping/virtualization to occur. no, at one time one use 1 input encoding, 1 output encoding and 1 font. Input encoding let TeX know which glyph is targeted. Output encoding let TeX associate a slot in the font which is related to the tageted glyph. When using MlTeX option you only say to TeX to pick up 2 slots of the font to produce the glyph inside the dvi (and let on the side the original font slot). So, encodings should never differ and the only scholar-case for which a pb could occur is when the 2 basic slots (in case of e-acute, the "e" and the "acute" slots) are different in the fonts in use. In nearly 14 years i use MlTeX i never fell on this pb, but you certainly did... DR> I think some day soon, we will have format generation on demand, like we have DR> font generation on demand, so that this will no longer be an issue. DR> I actually wonder why this has not yet been done. why not... --bg