Received: by nummer-3.proteosys id <01C19443.8F1DC78C@nummer-3.proteosys>; Thu, 3 Jan 2002 11:44:02 +0100 Return-Path: <@vm.gmd.de:LATEX-L@DHDURZ1.BITNET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.8F1DC78C" x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: Re: fontdef issues Date: Sat, 4 Jan 1992 18:50:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 474 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.8F1DC78C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > -I looked into the cmr files and noticed that for example cmr17 = actually > -is a font designed for 17.28pt. This opens the question of how to = organize > -fontshape defs again. > > -I currently think that it might be better to say something like > - <17.28>cmr17 > -instead of the white lie calling this <17>cmr17. > > Point size is a fairly abstract measurement which has no bearing > on any physical feature of printed letters. As long as all the > "17pt" type is consistent... I agree with Don that two 10pt fonts may not be the same, but this does not mean that we shouldn't think of the point size in NFSS as a measure that allows absolute comparison. Say it this way: fontdef files should be set up in a way that fonts at the same point size match (whatever this means, don't ask more than one designer a time:-) But the problem above is not a gutt feeling one, it is a question of a shortcut implemented in release 1 that fires back when scaling comes into play. For example, requesting a \fontsize{14}{17pt} cmtt font with the current fontdef files will give you cmtt at14.4pt since this is the magstep value where the font usually exists but if we use a scaled fontshape def like ...<9>cmtt9<10->cmtt10 then requesting 14pt will give us 14pt and thus we fail. In my feeling the best handling is to correct the logic and put either real magstep sizes into the <...> or switch to non magstep sizes, which is probably a no-no in the TeX world. (Note, that with computer typesetting magsteps are not so common) cheers Frank ------_=_NextPart_001_01C19443.8F1DC78C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: fontdef issues

>
> -I looked into the cmr files and noticed that = for example cmr17 actually
> -is a font designed for 17.28pt. This opens the = question of how to organize
> -fontshape defs again.
>
> -I currently think that it might be better to = say something like
> -   <17.28>cmr17
> -instead of the white lie calling this = <17>cmr17.
>
> Point size is a fairly abstract measurement = which has no bearing
> on any physical feature of printed letters. As = long as all the
> "17pt" type is consistent...

I agree with Don that two 10pt fonts may not be the = same, but this does
not mean that we shouldn't think of the point size in = NFSS as a
measure that allows absolute comparison. Say it this = way: fontdef files
should be set up in a way that fonts at the same = point size match
(whatever this means, don't ask more than one = designer a time:-)

But the problem above is not a gutt feeling one, it is = a question of a
shortcut implemented in release 1 that fires back = when scaling comes
into play.

For example, requesting a \fontsize{14}{17pt} cmtt = font with the
current fontdef files will give you cmtt at14.4pt = since this is the
magstep value where the font usually exists but if we = use a scaled
fontshape def like  = ...<9>cmtt9<10->cmtt10   then requesting 14pt = will
give us 14pt and thus we fail.

In my feeling the best handling is to correct the = logic and put either
real magstep sizes into the <...> or switch to = non magstep sizes,
which is probably a no-no in the TeX world. (Note, = that with computer
typesetting magsteps are not so common)

cheers Frank

------_=_NextPart_001_01C19443.8F1DC78C--