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 f14GGM716656 for ; Sun, 4 Feb 2001 17:16:22 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f14GHD715335 . for ; Sun, 4 Feb 2001 17:17:16 +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 f14GGI718786 for ; Sun, 4 Feb 2001 17:16:18 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08EC5.D0410F00" 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 RAA16330 for ; Sun, 4 Feb 2001 17:16:17 +0100 (MET) 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 f14GGG718780 for ; Sun, 4 Feb 2001 17:16:16 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <5.A2AA8C05@mail.listserv.gmd.de>; Sun, 4 Feb 2001 17:16:11 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 486668 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sun, 4 Feb 2001 17:16:10 +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 RAA24659 for ; Sun, 4 Feb 2001 17:16:09 +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 RAA48752 for ; Sun, 4 Feb 2001 17:16:09 +0100 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f14GG7u12757 for ; Sun, 4 Feb 2001 17:16:08 +0100 (MET) Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 14PRpZ-0007Zt-00 for LATEX-L@urz.uni-heidelberg.de; Sun, 4 Feb 2001 17:16:01 +0100 Received: from manz-3e364712.pool.mediaways.net ([62.54.71.18] helo=istrati.zdv.uni-mainz.de) by mrvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14PRpL-0007fR-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Sun, 4 Feb 2001 17:15:48 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id RAA22481; Sun, 4 Feb 2001 17:13:55 +0100 In-Reply-To: <200102041246.f14CkjS18998@smtp.wanadoo.es> References: <200102041246.f14CkjS18998@smtp.wanadoo.es> Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: glyph collections viz font encodings Date: Sun, 4 Feb 2001 17:13:54 +0100 Message-ID: <14973.32706.432640.436896@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" 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: 3704 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08EC5.D0410F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Javier, > Apparently, the sample always loads the ot1 variants, no matter > which encoging is selected. I think that you mean > > \DeclareRobustCommand\selectfont ...etc. > > instead of > > \DeclareRobustCommand\Xselectfont ...etc. hmmm, yes. plead guilty on that one. thought i had tested it after = making final changes from the private version to the one overwriting the nfss primitives, but ... > But anyway... yes, anyway. please everybody: change the above in the sample if you try = it. > As you know, I was experinmenting a couple of month ago with this = idea > in my draft for Lambda (the multilingual environment for Omega). was actually not aware of that (that you experimented with multiple = encodings) > However, I found several problems. For example: > - if I say \fontencoding{T1,OT1} we will get t1cmr which points to = another > font (ec) and not to a t1 encoded cmr, perhaps we should have that as a separate debate, but the ec fonts where supposed to be extended cmr at least this is what they started out to = be. I know that Joerg in the end did one or the other change but at least the original intention was that those fonts should have been = indistinguishable on their common subset of glyphs (and this is why in LaTeX they are = considered both family cm). if a lot of people think this is not the case then this opens an = important discussion about what to do with them, but it doesn't seem to me a = criticism or a problem with the general approach taken in my sample code. > - more importantly, we lost the control of the final result, because > a faked accented letter may be not exactly the same as an actual = composite > letter. It so happens that no TeX installations are the same and = perhaps > a different font in selected in another system just because a file = has not > been installed. but this is true already, isn't it? as of today a formatting of latex = document depends on a number of factors, one of which is the available fonts. so = 100% output compatibility is only achieved if you - have an identical set of fd files - have identical metrics (this was especially with PostScript fonts an = issue in the past) - actually have the fonts installed that the fd files and metrics are pointing to. so i don't see that the situation would get a different quality. Agreed, = with more possibilities you are likely (potentially at least) to get a wider = range of results; but on the other hand either you let the system take responsibility (which means trying to find fonts suitable for the = intended script (glyph collection)) or you force this selection onto the user. = And we know that the latter is unsatisfactory as well since not many people do understand why they need to say \usepackage[...]{fontenc} etc, or = rightly feel that they should not have to worry about it. i don't really see that there is a chance in the world to achieve 100% = output compatibility between sites unless you enforce a far more rigid scheme = (which isn't really possible). I mean you would need to define a far bigger set = of files to be untouchable and required and you need to also enforce and = you don't have additional files that might change your setup. if I now write a document and specify \fontencoding{T1} it might not run = at all at a site not having T1 fonts (though such a site is in theory not = allowed to exist) or it might switch to ec as default fonts, while with a range = of encodings i would get a result "closer" to the intended output. also please note that my code (after your fix:-) does both: you can = still specify a single encoding and then only that encoding will get used ie = you get the situation as it is now where the user has total control (assuming = that fd files are the same). > Despite that, I think that is the right way, and I'm studying how to = solve > these issues. Any ideas? do you have any other issues than the two above? you mentioned them as = "for example". cheers frank ------_=_NextPart_001_01C08EC5.D0410F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: glyph collections viz font encodings

Javier,

 > Apparently, the sample always loads the ot1 = variants, no matter
 > which encoging is selected. I think that = you mean
 >
 > = \DeclareRobustCommand\selectfont    ...etc.
 >
 > instead of
 >
 > = \DeclareRobustCommand\Xselectfont    ...etc.

hmmm, yes. plead guilty on that one. thought i had = tested it after making
final changes from the private version to the one = overwriting the nfss
primitives, but ...

 > But anyway...

yes, anyway. please everybody: change the above in the = sample if you try it.

 > As you know, I was experinmenting a couple = of month ago with this idea
 > in my draft for Lambda (the multilingual = environment for Omega).

was actually not aware of that (that you experimented = with multiple encodings)

 > However, I found several problems. For = example:
 > - if I say \fontencoding{T1,OT1} we will = get t1cmr which points to another
 >   font (ec) and not to a t1 = encoded cmr,

perhaps we should have that as a separate debate, but = the ec fonts where
supposed to be extended cmr at least this is what = they started out to be. I
know that Joerg in the end did one or the other = change but at least the
original intention was that those fonts should have = been indistinguishable on
their common subset of glyphs (and this is why in = LaTeX they are considered
both family cm).

if a lot of people think this is not the case then = this opens an important
discussion about what to do with them, but it doesn't = seem to me a criticism
or a problem with the general approach taken in my = sample code.

 > - more importantly, we lost the control of = the final result, because
 >   a faked accented letter may be = not exactly the same as an actual composite
 >   letter. It so happens that no = TeX installations are the same and perhaps
 >   a different font in selected = in another system just because a file has not
 >   been installed.

but this is true already, isn't it? as of today a = formatting of latex document
depends on a number of factors, one of which is the = available fonts. so 100%
output compatibility is only achieved if you

 - have an identical set of fd files
 - have identical metrics (this was especially = with PostScript fonts an issue
   in the past)
 - actually have the fonts installed that the fd = files and metrics are
   pointing to.

so i don't see that the situation would get a = different quality. Agreed, with
more possibilities you are likely (potentially at = least) to get a wider range
of results; but on the other hand either you let the = system take
responsibility (which means trying to find fonts = suitable for the intended
script (glyph collection)) or you force this = selection onto the user. And we
know that the latter is unsatisfactory as well since = not many people do
understand why they need to say = \usepackage[...]{fontenc} etc, or rightly feel
that they should not have to worry about it.

i don't really see that there is a chance in the world = to achieve 100% output
compatibility between sites unless you enforce a far = more rigid scheme (which
isn't really possible). I mean you would need to = define a far bigger set of
files to be untouchable and required and you need to = also enforce and you
don't have additional files that might change your = setup.

if I now write a document and specify = \fontencoding{T1} it might not run at
all at a site not having T1 fonts (though such a site = is in theory not allowed
to exist) or it might switch to ec as default fonts, = while with a range of
encodings i would get a result "closer" to = the intended output.


also please note that my code (after your fix:-) does = both: you can still
specify a single encoding and then only that encoding = will get used ie you get
the situation as it is now where the user has total = control (assuming that fd
files are the same).

 > Despite that, I think that is the right = way, and I'm studying how to solve
 > these issues. Any ideas?

do you have any other issues than the two above? you = mentioned them as "for
example".

cheers
frank

------_=_NextPart_001_01C08EC5.D0410F00--