Received: by nummer-3.proteosys id <01C19443.91054654@nummer-3.proteosys>; Thu, 3 Jan 2002 11:44:05 +0100 Return-Path: <@vm.gmd.de:LATEX-L@DHDURZ1.BITNET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.91054654" 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 x-to: LaTeX-L@vm.urz.uni-heidelberg.de Content-class: urn:content-classes:message Subject: Sebastian is right, as usual (was: NFSS2 alpha comments) Date: Tue, 7 Jan 1992 12:37:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Rainer Schoepf" Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 499 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.91054654 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sebastian has laid the finger on one of the crucial shortcomings of TeX itself: there is no way to know whether a .tfm file can be loaded or not. That means that this has to be decided beforehand, so that suitable font definitions can be supplied. [This process may, of course, be automated.] I think that Sebastian's example #4 exhibits a shortcoming of nfss2\alpha: it is not possible to apply a function map only to a certain range. Therefore I think we should add this (as he suggests in thought #4). Re though #5 (the mismatch between the simple size (e.g. 14) and the scaling factor (14.4)): Yes, I think we should go away from the "14 really means 14.4" business. 1. String pool size is not really the problem, as Sebastian has shown. 2. If you load "cmr17 at17.28pt" you get the same as "cmr17" since the design size of cmr17 is 17.28. 3. The problem of TeX arithmetic: hmmm, but here one could simply go to dimen arithmetic which it was anyway in the beginning, wasn't it? 4. Finally, this could indeed be the application for the "nearby size" feature. What do you think, Sebastian? As regards to math typesetting, Chris and myself have discussed a possible solution in the paper Frank sent around on this list recently. It is admittedly very terse, but I think that it addresses exactly the points Sebastian raised, although it has to be reconsidered in the light of the discussion on the text fonts that takes place here. Rainer ------_=_NextPart_001_01C19443.91054654 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sebastian is right, as usual (was: NFSS2 alpha = comments)

Sebastian has laid the finger on one of the crucial = shortcomings of
TeX itself: there is no way to know whether a .tfm = file can be loaded
or not. That means that this has to be decided = beforehand, so that
suitable font definitions can be supplied. [This = process may, of
course, be automated.]

I think that Sebastian's example #4 exhibits a = shortcoming of
nfss2\alpha: it is not possible to apply a function = map only to a
certain range. Therefore I think we should add this = (as he suggests in
thought #4).

Re though #5 (the mismatch between the simple size = (e.g. 14) and the
scaling factor (14.4)): Yes, I think we should go = away from the "14
really means 14.4" business.

1. String pool size is not really the problem, as = Sebastian has shown.
2. If you load "cmr17 at17.28pt" you get = the same as "cmr17" since the
   design size of cmr17 is 17.28.
3. The problem of TeX arithmetic: hmmm, but here one = could simply go
   to dimen arithmetic which it was anyway = in the beginning, wasn't
   it?
4. Finally, this could indeed be the application for = the "nearby size"
   feature. What do you think, = Sebastian?

As regards to math typesetting, Chris and myself have = discussed a
possible solution in the paper Frank sent around on = this list
recently. It is admittedly very terse, but I think = that it addresses
exactly the points Sebastian raised, although it has = to be
reconsidered in the light of the discussion on the = text fonts that
takes place here.

Rainer

------_=_NextPart_001_01C19443.91054654--