Received: by nummer-3.proteosys id <01C19443.9470EEAC@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.9470EEAC" 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:11:18 +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: 520 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.9470EEAC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rainer says: > 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. I can make TeX do this (but see another message from me). BUT, equally relevant to some of Sebastian's desires, is that it is extremely difficult for TeX to work out what sizes of a font can be produced on all the printers on which the document may need to be = printed. > 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). and we certainly need this for mathsizes which, in some ways, are like "one extra font at each size". > 1. String pool size is not really the problem, as Sebastian has shown. I hope this is true! > 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? there is a more general need for something like this. > 4. Finally, this could indeed be the application for the "nearby size" > feature. What do you think, Sebastian? Maybe. > 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. Yes, it could have been "an alternate way to treat fonts". chris ------_=_NextPart_001_01C19443.9470EEAC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Sebastian is right, as usual (was: NFSS2 alpha = comments)

Rainer says:
> 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.
I can make TeX do this (but see another message from = me).

BUT, equally relevant to some of Sebastian's desires, = is that it is
extremely difficult for TeX to work out what sizes of = a font can be
produced on all the printers on which the document = may need to be printed.

> 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).
and we certainly need this for mathsizes which, in = some ways, are
like "one extra font at each size".


> 1. String pool size is not really the problem, as = Sebastian has shown.
I hope this is true!

> 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?
there is a more general need for something like = this.

> 4. Finally, this could indeed be the application = for the "nearby size"
>    feature. What do you think, = Sebastian?
Maybe.

> 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.
Yes, it could have been "an alternate way to = treat fonts".


chris

------_=_NextPart_001_01C19443.9470EEAC--