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 f18DbQH30573 for ; Thu, 8 Feb 2001 14:37:26 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f18DbPd13428 . for ; Thu, 8 Feb 2001 14:37:25 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091D4.4601EF00" 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 f18DbP707017 for ; Thu, 8 Feb 2001 14:37:25 +0100 (MET) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id OAA15855 for ; Thu, 8 Feb 2001 14:37:24 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f18DbM707005 for ; Thu, 8 Feb 2001 14:37:24 +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 <1.194A490D@mail.listserv.gmd.de>; Thu, 8 Feb 2001 14:37:17 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488237 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 8 Feb 2001 14:37:19 +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 OAA19107 for ; Thu, 8 Feb 2001 14:37:18 +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 OAA30686 for ; Thu, 8 Feb 2001 14:37:18 +0100 Received: from lumiere.idris.fr (lumiere.idris.fr [130.84.8.14]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f18DbHu12552 for ; Thu, 8 Feb 2001 14:37:17 +0100 (MET) Received: from mira.idris.fr (gaulle@mira.idris.fr [130.84.12.100]) by lumiere.idris.fr (8.9.3/8.9.3) with ESMTP id OAA464727 for ; Thu, 8 Feb 2001 14:37:17 +0100 (CET) Received: (from gaulle@localhost) by mira.idris.fr (8.9.3/8.9.3) id OAA92694; Thu, 8 Feb 2001 14:37:15 +0100 Return-Path: Content-class: urn:content-classes:message Subject: Re: default inputenc/fontenc tight to language Date: Thu, 8 Feb 2001 14:37:15 +0100 Message-ID: <14978.41227.305822.700930@mira.idris.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Bernard GAULLE (CNRS/IDRIS - France) " 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: 3752 This is a multi-part message in MIME format. ------_=_NextPart_001_01C091D4.4601EF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Carlisle writes: > > Yes mltex is quite appropriate > > I wasn't criticising, just checking that I understood you correctly. > > > for a default format for French as well > > as for all european languages and produced glyphs a far better... > "better" than what? let's say all other cm like fonts. Let's compare what is compareable. > Couldn't one produce a VF file that produced > identical results to mltex's positioning of the accents? it should but it is not at this time. > I don't think that you'll get universal agreement about is it really any argument here? > > Since Web2c is a standard, the --mltex option is standard too. > > while it's reasonable to ask all TeX implementors to implement Knuth > specified features like VF support (I could mention some guilty = parties > at this point:-) I don't think it reasonable to suggest that they > "should" implement features just because they happen to be = implemented > in web2c even if that is by far the most commonly used tex. nobody is asked to implement what they don't need. Please let english speaking people, for example, continue to use default cm if they like it. And let other europeans continue to use the --mltex option of web2c while they don't need more for their default format. I don't say that the solution is not going via virtual fonts; i just say that quality is not sufficient at this time and that more improvements are necessary: i think to accent placement made dynamically by the output driver on the basis of \special commands initiated by linguistic style. No so complicate. Clearly i refuse any solution which would give me, defaultly, a less quality output, due to the default (v)fonts in use. --bg ------_=_NextPart_001_01C091D4.4601EF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default inputenc/fontenc tight to language

David Carlisle writes:
 > > Yes mltex is quite appropriate
 >
 > I wasn't criticising, just checking that I = understood you correctly.
 >
 > > for a default format for French as = well
 > > as for all european languages and = produced glyphs a far better...
 > "better" than what?

let's say all other cm like fonts. Let's compare what = is
compareable.

 > Couldn't one produce a VF file that = produced
 > identical results to mltex's positioning = of the accents?

it should but it is not at this time.

 > I don't think that you'll get universal = agreement about

is it really any argument here?

 > >  Since Web2c is a standard, the = --mltex option is standard too.
 >
 > while it's reasonable to ask all TeX = implementors to implement Knuth
 > specified features like VF support (I = could mention some guilty parties
 > at this point:-) I don't think it = reasonable to suggest that they
 > "should" implement features just = because they happen to be implemented
 > in web2c even if that is by far the most = commonly used tex.

nobody is asked to implement what they don't need. = Please let
english speaking people, for example, continue to use = default cm
if they like it. And let other europeans continue to = use the --mltex
option of web2c while they don't need more for their = default format.

I don't say that the solution is not going via virtual = fonts;
i just say that quality is not sufficient at this = time and that
more improvements are necessary: i think to accent = placement made
dynamically by the output driver on the basis of = \special commands
initiated by linguistic style. No so = complicate.

Clearly i refuse any solution which would give me, = defaultly,
a less quality output, due to the default (v)fonts in = use.

  --bg

------_=_NextPart_001_01C091D4.4601EF00--