Sun, 18 Feb 2001 13:05:12 +0100
> Frank Mittelbach a écrit :
> > 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
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
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
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