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 f15Bg4719752 for ; Mon, 5 Feb 2001 12:42:04 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f15Bgx718598 . for ; Mon, 5 Feb 2001 12:43:00 +0100 MIME-Version: 1.0 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 f15Bg3714807 for ; Mon, 5 Feb 2001 12:42:03 +0100 (MET) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F68.A8EF4E00" 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 MAA07546 for ; Mon, 5 Feb 2001 12:42:03 +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 f15Bg2714803 for ; Mon, 5 Feb 2001 12:42:02 +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.7DB79AC6@mail.listserv.gmd.de>; Mon, 5 Feb 2001 12:41:57 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 486957 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 5 Feb 2001 12:41:59 +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 MAA06397 for ; Mon, 5 Feb 2001 12:41:57 +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 MAA26460 for ; Mon, 5 Feb 2001 12:41:57 +0100 Received: from smtp.wanadoo.es (m1smtpisp02.wanadoo.es [62.36.220.21] (may be forged)) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f15Bfuu18187 for ; Mon, 5 Feb 2001 12:41:57 +0100 (MET) Received: from wanadoo.es (m1wmail1.wanadoo.es [62.36.220.41]) by smtp.wanadoo.es (8.10.2/8.10.2) with ESMTP id f15BfuS19825 for ; Mon, 5 Feb 2001 12:41:56 +0100 (MET) Return-Path: x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id MAA06398 x-xam3-api-version: 1.1.11.1.5 x-senderip: 195.53.220.3 Content-class: urn:content-classes:message Subject: Re: glyph collections viz font encodings Date: Mon, 5 Feb 2001 12:41:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "jbezos" 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: 3707 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08F68.A8EF4E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank, Chris, I must admit that I'm too critic with my own macros and that I try to study every possible implication of them, even if finally they are unimportant. > > 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. Actually, this is not a criticism to this approach, just an issue. While there are free PostScript ot1cmr fonts, there are only MF t1cmr ones, = which to me is a huge difference. Sometimes I combine Palatino (T1) and cmtt (OT1), and \selectfont{T1,OT1} is not enough. The solution I took in my macros = was to allow explicit declarations like: \SetFontEnconding{cmtt}{OT1} > > - 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. But TeX complains, except in the case of locally generated metrics. One of the solutions I considered was to generate a file recording the decisions taken in a system when a document is typeset, so that if we really want to ensure that TeX complains if there is a different configuration we can distribute that file with the main .tex ones. And after all if we really really want a certain layout the obvius solution is to distribute only a pdf file... > [Chris]-- differences in the metrics (these can cause major = differences in > the typesetting). Yes, differences in the metrics, which can reshape the whole document. > 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". There are in part related to the fact that a language or a script can provide a set of default encogings. (Note: in the current draft for Lambda there are files for both languages and scripts). But I think that: > 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). is the best solution. Cheers Javier _________________________________________________________________________= _____ Consigue tu cuenta de correo universal y gratuita en = http://webmail.wanadoo.es ------_=_NextPart_001_01C08F68.A8EF4E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: glyph collections viz font encodings

Frank, Chris,

I must admit that I'm too critic with my own macros = and that
I try to study every possible implication of them, = even if
finally they are unimportant.

>  > 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.

Actually, this is not a criticism to this approach, = just an issue. While
there are free PostScript ot1cmr fonts, there are = only MF t1cmr ones, which
to me is a huge difference. Sometimes I combine = Palatino (T1) and cmtt
(OT1),
and \selectfont{T1,OT1} is not enough. The solution I = took in my macros was
to allow explicit declarations like:
  \SetFontEnconding{cmtt}{OT1}

>  > - 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.

But TeX complains, except in the case of locally = generated metrics.
One of the solutions I considered was to generate a = file recording the
decisions taken in a system when a document is = typeset, so that if we
really want to ensure that TeX complains if there is = a different
configuration we can distribute that file with the = main .tex ones.
And after all if we really really want a certain = layout the obvius
solution is to distribute only a pdf file...

> [Chris]-- differences in the metrics (these can = cause major differences in
> the typesetting).

Yes, differences in the metrics, which can reshape the = whole document.

> 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".

There are in part related to the fact that a language = or a script
can provide a set of default encogings. (Note: in the = current draft
for Lambda there are files for both languages and = scripts).
But I think that:

> 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).

is the best solution.

Cheers
Javier

________________________________________________________________= ______________
Consigue tu cuenta de correo universal y gratuita en = http://webmail.wanadoo.es

------_=_NextPart_001_01C08F68.A8EF4E00--