Received: by nummer-3.proteosys id <01C19443.9483454C@nummer-3.proteosys>; Thu, 3 Jan 2002 11:44:11 +0100 Return-Path: <@vm.gmd.de:LATEX-L@DHDURZ1.BITNET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.9483454C" 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: Sebastian is right, as usual (was: NFSS2 alpha comments) Date: Wed, 8 Jan 1992 19:13:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 521 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.9483454C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A few comments on "the trials of (St) Sebastian": 1. He wants, quite reasonably, to be able to test whether a particular .TFM file exists on the system. Whilst this is possible, it gets into areas of TeX which are system/implementation dependent. I have just, fairly easily, set up the environment for EMTeX to make this possible on my PC---but until I actually tried it, I was not sure if it would work. Therefore the NFSS so far assumes that the fontdef file is set-up by someone who knows what .TFM files are available on the system and who should ensure that it never tries to load a "nonexistent external font". Maybe this philosophy should change? I have to admit that I am very glad that I have never had to do this job of setting up a fontdefs file partly for this reason: the need to know exactly what fonts are available. Therefore, his function "cm" is an abuse of the current NFSS. 3. Assuming that what he is trying to do in his "cmscale" function is also for a system which has only a discrete collection of actual font files available (ie fonts for the printer to use) then he is committing a perhaps even more serious abuse since, for sizes greater than 11, this function can allow Tex to work with font-metrics (eg cmr17 at 22pt) for fonts which will not be printable on that system. So such a system would need to check that the size of font selected could printed: a much more difficult task than checking the existence of a .TFM file! Thus, either the NFSS or Sebastian must change (and who would want to change Sebastian?). If his ideas could be made more robust, then they would clearly be preferable: eg more flexible, ability to write generic, non system-specific fontdef files, less string-space. As he points out, another requirement for this to work is some kind of "decimal arithmetic": this is not the only place where such arithmetic would be useful. So the crucial question is: Should (and can) the NFSS philosophy change to allow generic, rather = than system-specific, fontdef files? chris ------_=_NextPart_001_01C19443.9483454C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Sebastian is right, as usual (was: NFSS2 alpha = comments)

A few comments on "the trials of (St) = Sebastian":

1.  He wants, quite reasonably, to be able to = test whether a
particular .TFM file exists on the system.

Whilst this is possible, it gets into areas of TeX = which are
system/implementation dependent.  I have just, = fairly easily, set up
the environment for EMTeX to make this possible on my = PC---but until
I actually tried it, I was not sure if it would = work.

Therefore the NFSS so far assumes that the fontdef = file is set-up by
someone who knows what .TFM files are available on = the system and who
should ensure that it never tries to load a = "nonexistent external
font".  Maybe this philosophy should = change?  I have to admit that I
am very glad that I have never had to do this job of = setting up a
fontdefs file partly for this reason: the need to = know exactly what
fonts are available.

Therefore, his function "cm" is an abuse of = the current NFSS.

3.  Assuming that what he is trying to do in his = "cmscale" function is
also for a system which has only a discrete = collection of actual font
files available (ie fonts for the printer to use) = then he is
committing a perhaps even more serious abuse since, = for sizes greater
than 11, this function can allow Tex to work with = font-metrics (eg
cmr17 at 22pt) for fonts which will not be printable = on that system.
So such a system would need to check that the size of = font selected
could printed: a much more difficult task than = checking the existence
of a .TFM file!

Thus, either the NFSS or Sebastian must change (and = who would want to
change Sebastian?).  If his ideas could be made = more robust, then they
would clearly be preferable: eg more flexible, = ability to write
generic, non system-specific fontdef files, less = string-space.

As he points out, another requirement for this to work = is some kind of
"decimal arithmetic": this is not the only = place where such arithmetic
would be useful.

So the crucial question is:

  Should (and can) the NFSS philosophy change to = allow generic, rather than
   system-specific, fontdef files?



chris

------_=_NextPart_001_01C19443.9483454C--