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 f18FMWH30970 for ; Thu, 8 Feb 2001 16:22:32 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f18FMWd13740 . for ; Thu, 8 Feb 2001 16:22:32 +0100 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 f18FMV717584 for ; Thu, 8 Feb 2001 16:22:31 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091E2.F4AD2C00" 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 QAA16010 for ; Thu, 8 Feb 2001 16:22:31 +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 f18FMT717580 for ; Thu, 8 Feb 2001 16:22:29 +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 <12.C872FEA1@mail.listserv.gmd.de>; Thu, 8 Feb 2001 16:22:24 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488504 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 8 Feb 2001 16:22:25 +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 QAA22585 for ; Thu, 8 Feb 2001 16:22:24 +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 QAA34226 for ; Thu, 8 Feb 2001 16:22:25 +0100 Received: from zambeze.ujf-grenoble.fr (zambeze.ujf-grenoble.fr [152.77.2.3]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f18FMOu15642 for ; Thu, 8 Feb 2001 16:22:24 +0100 (MET) Received: from mozart.ujf-grenoble.Fr (mozart.ujf-grenoble.fr [193.54.241.5]) by zambeze.ujf-grenoble.fr (Pro-8.9.3/8.9.3/Configured by AD & JE 25/10/1999) with ESMTP id QAA24464 for ; Thu, 8 Feb 2001 16:22:24 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.Fr (8.9.3/8.8.5) id QAA23205; Thu, 8 Feb 2001 16:22:23 +0100 (MET) In-Reply-To: <200102081402.OAA16774@penguin.nag.co.uk> References: <14978.41227.305822.700930@mira.idris.fr> <200102081402.OAA16774@penguin.nag.co.uk> Return-Path: X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Content-class: urn:content-classes:message Subject: Re: default inputenc/fontenc tight to language Date: Thu, 8 Feb 2001 16:22:23 +0100 Message-ID: <200102081522.QAA23205@mozart.ujf-grenoble.Fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Thierry Bouche" 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: 3754 This is a multi-part message in MIME format. ------_=_NextPart_001_01C091E2.F4AD2C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey David, this is a troll... Concernant =AB Re: default inputenc/fontenc tight to language =BB, David = Carlisle =E9crit :=A0=AB =BB But more interesting to me is to know =BB whether any differences are due to technical abilities of the two =BB systems of course not. VF supersedes mltex completely. Moreover, VF allows to kern differently accented letters from the base, which mltex can't. =BB or whether they are just different design choices by the authors =BB of the vf fonts. One single-user french group has been fighting for years against J=F6rg Knappen's DC/EC fonts. Among the reasons were, if i remember well: accents too flat, dieresis too low and bold (it's an umlaut, and not a dieresis, in fact), some inaccuracies in weight between misc symbols and text ones. Good fonts have different accents over upper case letters than over lowercase/small caps (the small caps accents are not reduced cap-accents, but same as lc). CM, either with mltex or VF, can't provide these refinements; EC could, but not as perfect as we would like. Discussing about that with J=F6rg during the years inbetween DC and EC, he talled me that he had got feedback from 2 or 3 french users about the glyphs concerning them. So it seems that nobody cares that much about the `quality': neither CM nor EC being complete top quality solutions for french typography. Automatically placed accents like with \accent are typically too high, and sometimes too much centered (the acute accents should be somewhat to the right of the width of an e, CM is essentially correct in this respect; the circumflex is too high and maybe too light). There is no reason why a VF should emulate \accent, in fact Thanh, when preparing fonts for czech with special accents, worked hard to obtain less slopy cap-accents, and better placed lc accents. =BB > i think to accent placement made dynamically by the output driver = on =BB > the basis of \special commands =BB =BB Unless I am totally confused, that isn't what mltex does, is it? Nobody does it! It could be an opentype feature (reacting to a language tag). And how would you manage to make that device independant (you're talking of a _default_ system!)? That could be done with virtual fonts, and family (NOT encoding) switches depending on languages... Notice that I _never_ saw any argument between germans and frenchs about the dieresis in Times. Do they _really_ need distinct glyphs? =BB > Clearly i refuse any solution which would give me, defaultly, =BB > a less quality output, Bernard, I say it politely, you're plain wrong. We're talking about = default encodings, and you're answering about existing font _shapes_. Choosing anything with less features than T1 as default encoding restricts the possible quality with any font set (once again, kerns + hyphenation \implies T1 or LY1). =BB Fair enough. Getting quality output is of course the aim of the = game. But precisely, here the problem is to devise the good defaults that don't limitate quality. We're not expecting from article.cls that it be an example of `good layout quality', it's only here to define the standard markup for preprints. We're not expecting that the default font used be nice to look at, we're just expecting that the right glyph be in the right slot, and that everything that should end on the page be where it should, so that we can safely read the preprint, or print it as _copy_. An actual typesetter will use his own system to generate the films, using his own defaults, that may or may not be latex's ones. Aesthetics are totally irrelevant in the current discussion, imho. Thierry Bouche __ =AB Ils vivent pour vivre, et nous, h=E9las=A0! nous vivons pour = savoir. =BB Charles Baudelaire, Paris. ------_=_NextPart_001_01C091E2.F4AD2C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default inputenc/fontenc tight to language

Hey David, this is a troll...

Concernant =AB Re: default inputenc/fontenc tight to = language =BB, David Carlisle =E9crit :=A0=AB
=BB But more interesting to me is to know
=BB whether any differences are due to technical = abilities of the two
=BB systems

of course not. VF supersedes mltex completely. = Moreover, VF allows to
kern differently accented letters from the base, = which mltex can't.

=BB or whether they are just different design choices = by the authors
=BB of the vf fonts.

One single-user french group has been fighting for = years against J=F6rg
Knappen's DC/EC fonts. Among the reasons were, if i = remember well:
accents too flat, dieresis too low and bold (it's an = umlaut, and not a
dieresis, in fact), some inaccuracies in weight = between misc symbols
and text ones. Good fonts have different accents over = upper case
letters than over lowercase/small caps (the small = caps accents are not
reduced cap-accents, but same as lc). CM, either with = mltex or VF,
can't provide these refinements; EC could, but not as = perfect as we
would like. Discussing about that with J=F6rg during = the years inbetween
DC and EC, he talled me that he had got feedback from = 2 or 3 french
users about the glyphs concerning them. So it seems = that nobody cares
that much about the `quality': neither CM nor EC = being complete top
quality solutions for french typography. = Automatically placed accents
like with \accent are typically too high, and = sometimes too much
centered (the acute accents should be somewhat to the = right of the
width of an e, CM is essentially correct in this = respect; the
circumflex is too high and maybe too light). There is = no reason why a
VF should emulate \accent, in fact Thanh, when = preparing fonts for
czech with special accents, worked hard to obtain = less slopy
cap-accents, and better placed lc accents.

=BB >  i think to accent placement made = dynamically by the output driver on
=BB >  the basis of \special commands
=BB
=BB Unless I am totally confused, that isn't what = mltex does, is it?

Nobody does it! It could be an opentype feature = (reacting to a
language tag). And how would you manage to make that = device
independant (you're talking of a _default_ system!)? = That could
be done with virtual fonts, and family (NOT encoding) = switches
depending on languages... Notice that I _never_ saw = any argument
between germans and frenchs about the dieresis in = Times. Do they
_really_ need distinct glyphs?

=BB > Clearly i refuse any solution which would = give me, defaultly,
=BB > a less quality output,

Bernard, I say it politely, you're plain wrong. We're = talking about default
encodings, and you're answering about existing font = _shapes_. Choosing
anything with less features than T1 as default = encoding restricts the
possible quality with any font set (once again, kerns = + hyphenation
\implies T1 or LY1).

=BB Fair enough. Getting quality output is of course = the aim of the game.

But precisely, here the problem is to devise the good = defaults that
don't limitate quality. We're not expecting from = article.cls that it
be an example of `good layout quality', it's only = here to define the
standard markup for preprints. We're not expecting = that the default
font used be nice to look at, we're just expecting = that the right
glyph be in the right slot, and that everything that = should end on the
page be where it should, so that we can safely read = the preprint, or
print it as _copy_.

An actual typesetter will use his own system to = generate the films,
using his own defaults, that may or may not be = latex's ones.
Aesthetics are totally irrelevant in the current = discussion, imho.

Thierry Bouche
__
  =AB Ils vivent pour vivre, et nous, = h=E9las=A0! nous vivons pour savoir. =BB
          &nbs= p;            = ;         Charles Baudelaire, = Paris.

------_=_NextPart_001_01C091E2.F4AD2C00--