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 f1IC7Ff13437 for ; Sun, 18 Feb 2001 13:07:15 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1IC7Ed22985 . for ; Sun, 18 Feb 2001 13:07:14 +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 f1IC79Q02122 for ; Sun, 18 Feb 2001 13:07:09 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C099A3.54EE5B80" 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 NAA15969 for ; Sun, 18 Feb 2001 13:07:09 +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 f1IC78Q02115 for ; Sun, 18 Feb 2001 13:07:08 +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 <4.24154B6E@mail.listserv.gmd.de>; Sun, 18 Feb 2001 13:06:59 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 489401 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sun, 18 Feb 2001 13:07:04 +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 NAA01504 for ; Sun, 18 Feb 2001 13:07:03 +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 NAA29522 for ; Sun, 18 Feb 2001 13:07:04 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1IC73x28028 for ; Sun, 18 Feb 2001 13:07:03 +0100 (MET) Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14UScJ-0001nI-00 for LATEX-L@urz.uni-heidelberg.de; Sun, 18 Feb 2001 13:07:03 +0100 Received: from manz-3e364815.pool.mediaways.net ([62.54.72.21] helo=istrati.zdv.uni-mainz.de) by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2) id 14USc6-0007Fj-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Sun, 18 Feb 2001 13:06:50 +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 NAA26690; Sun, 18 Feb 2001 13:05:13 +0100 In-Reply-To: <3A8EEF8E.E4ED93B7@ujf-grenoble.fr> References: <200102101651.f1AGpGi00601@smtp.wanadoo.es> <14983.4312.101767.632716@istrati.zdv.uni-mainz.de> <3A8EEF8E.E4ED93B7@ujf-grenoble.fr> Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id NAA01505 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, 18 Feb 2001 13:05:12 +0100 Message-ID: <14991.47736.879852.155072@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: 3968 This is a multi-part message in MIME format. ------_=_NextPart_001_01C099A3.54EE5B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Frank Mittelbach a =E9crit : > > > is there _anybody else_ who can come up with another reason why one = wants to > > restrict a list of possible encodings (of the same font, or say set = of > > glyphs!) other than some of the actual fonts are not suitable for = the target > > device, eg pdf output? > > well, no. I don't even agree that it's a good reason: make a virtual > font with the glyphs you want in the required encoding. If the = encoding > was meant for your language, then you can probably enhance the > typography. seriously Thierry, how many people can make a virtual font compared to = the number who can select an option on some package that will result in only = Type 1 fonts being used? so in my opinion as long as you have font families in non Type1 (and = that you perhaps have forever) it might be worth offering a simple way to be able = to request not using them for certain documents. > something harder: most of fonts declared as T are not = fully > compliant. most T1 tfms miss Ng, most TS1 miss \textmaried, etc. what > can be done at latex level about that? declare numerous encodings (T1 > from 8a, TS1 from 8a/8a+8x...) and find that most of the time asking = for > french+times will return that Times is not T1? this comes back to my claim that T1 has a number of pitfalls and the = fact that nearly no font other than European CM itself actually has all the slots = filled specified by T1 is one of them. Yes i'm seriously thinking that splitting TS1 into say, TSA (adobe = default) TSE (with expert set) and so on would be helpful to actually make sure that = if you have a font that claims to be in some encoding it really has the glyphs = of that encoding. Similar T1 should then be expanded to have companion encodings which are = used for fonts that do not have Ng etc. The number of encodings wouldn't grow that much, but then you could = really be sure that you get what you ask for and not just some square boxes in the output and some error messages from dvips. Of course to make this usable one would need to implement an extension = like the one I outlined a few days ago which supports specifying a list of acceptable encodings rather than being forced to have only a single = encoding. > > > What happens if for some reason > > > I like cyrillic times and latin palatino? > > > > first of all that needs to be specifiable and that is an = interesting problem > > in itself (though solvable in a decent way). > > It seems obvious to me that what you nedd here is a family whose T1 = set > points to palatino, and T2 to times. Latex requires standard markup = to > have portable & relatively independant content structure from font = sets, > etc. Customization should take place in the FD/VF rather than through > packages. Or am I silly? i wouldn't dare to comment on that, would I? :-) but i don't think that one should resolve such a request on FD/VF level. = it is not that you ask for palatino fonts and by some magic they look like = glyphs from Times the moment they are cyrillic glyphs (at least I don't think = you should think of it this way). I understand it more that the request is to typeset cyrillic text with a = Times font family while typesetting latin text in the same document with = palatino. So the specification should be one that ties the default family when typesetting in, say, French, to Palatino and to Times when typesetting = in, say Russian. The way you could do that in the xlang package i'm currently working on = would be to specify in the preamble of a document (or in a class file) = something like this: \SetLanguageCommandAction{french}{\rmdefault}{ptm} \SetLanguageCommandAction{russian}{\rmdefault}{ppl} frank ------_=_NextPart_001_01C099A3.54EE5B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: glyph collections viz font encodings

 > Frank Mittelbach a =E9crit :
 >
 > > is there _anybody else_ who can come = up with another reason why one wants to
 > > restrict a list of possible encodings = (of the same font, or say set of
 > > glyphs!) other than some of the = actual fonts are not suitable for the target
 > > device, eg pdf output?
 >
 > well, no. I don't even agree that it's a = good reason: make a virtual
 > font with the glyphs you want in the = required encoding. If the encoding
 > was meant for your language, then you can = probably enhance the
 > typography.

seriously Thierry, how many people can make a virtual = font compared to the
number who can select an option on some package that = will result in only Type
1 fonts being used?

so in my opinion as long as you have font families in = non Type1 (and that you
perhaps have forever) it might be worth offering a = simple way to be able to
request not using them for certain documents.


 > something harder: most of fonts declared as = T<something> are not fully
 > compliant. most T1 tfms miss Ng, most TS1 = miss \textmaried, etc. what
 > can be done at latex level about that? = declare numerous encodings (T1
 > from 8a, TS1 from 8a/8a+8x...) and find = that most of the time asking for
 > french+times will return that Times is not = T1?

this comes back to my claim that T1 has a number of = pitfalls and the fact that
nearly no font other than European CM itself actually = has all the slots filled
specified by T1 is one of them.

Yes i'm seriously thinking that splitting TS1 into = say, TSA (adobe default) TSE
(with expert set) and so on would be helpful to = actually make sure that if you
have a font that claims to be in some encoding it = really has the glyphs of
that encoding.

Similar T1 should then be expanded to have companion = encodings which are used
for fonts that do not have Ng etc.

The number of encodings wouldn't grow that much, but = then you could really be
sure that you get what you ask for and not just some = square boxes in the
output and some error messages from dvips.

Of course to make this usable one would need to = implement an extension like
the one I outlined a few days ago which supports = specifying a list of
acceptable encodings rather than being forced to have = only a single encoding.


 > >  > What happens if for some = reason
 > >  > I like cyrillic times and = latin palatino?
 >
 >
 > > first of all that needs to be = specifiable and that is an interesting problem
 > > in itself (though solvable in a = decent way).
 >
 > It seems obvious to me that what you nedd = here is a family whose T1 set
 > points to palatino, and T2 to times. Latex = requires standard markup to
 > have portable & relatively independant = content structure from font sets,
 > etc. Customization should take place in = the FD/VF rather than through
 > packages. Or am I silly?

i wouldn't dare to comment on that, would I? = :-)

but i don't think that one should resolve such a = request on FD/VF level. it is
not that you ask for palatino fonts and by some magic = they look like glyphs
from Times the moment they are cyrillic glyphs (at = least I don't think you
should think of it this way).

I understand it more that the request is to typeset = cyrillic text with a Times
font family while typesetting latin text in the same = document with palatino.

So the specification should be one that ties the = default family when
typesetting in, say, French, to Palatino and to Times = when typesetting in, say
Russian.

The way you could do that in the xlang package i'm = currently working on would
be to specify in the preamble of a document (or in a = class file) something
like this:

\SetLanguageCommandAction{french}{\rmdefault}{ptm}
\SetLanguageCommandAction{russian}{\rmdefault}{ppl}


frank

------_=_NextPart_001_01C099A3.54EE5B80--