[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: defining the script sizes via font dimens
- To: Frank Mittelbach <Frank.Mittelbach@Uni-Mainz.DE>
- Subject: Re: defining the script sizes via font dimens
- From: "Y&Y, Inc." <support@YandY.com>
- Date: Mon, 20 Oct 1997 18:17:06 -0400
- Cc: math-font-discuss@cogs.susx.ac.uk
Hi:
At 09:14 PM 97/10/20 +0100, Frank wrote:
>you do hit here on some of the very big TeX problem here and as long
>as TeX with its builtin rules doesn't care about this there is indeed
>not much point in providing any additional values from within the
>font. However I don't think that technically there is a big problem
>within TeX to make the rules in appendix G work with a small number of
>additional font dimens. And there is the etex project which provides
>an upward compatible extended TeX which could easily (IMHO) make use
>of such additional parameters if present. all that would be necessary is
>a) you do summarise your findings from work with Lucida and Math Times
>b) the etex people agree to support additional parameters for those
> findings in a)
As far as I remember them :-) Most of this was done 1990--1995,
and at my age, that is a long way to remember back...
>this would be award compatible, ie a normal TeX would not use those
>extra parameters
>I would very much welcome if version 2 or 3 of etex contains enough
>additional functionality that it would be worth supporting LaTeX on
>it. Of course all this has only a good chance if the majority of TeX
>users finds such an etex interesting enough to switch too, and of
>course this would also mean that the commerical implementations like
>Y&Y support etex (as a default) at some point in the future.
>The way etex is written this should not be a major problem, on
>platforms where the code is based on the web source this is in fact
>just a change file to the program.
Pain! Both implementations supporting dynamic memory allocations
are actually siginifcantly removed from the web source and would
be hard to `upgrade' to eTeX. Yet, I agree that if TeX is to survive
long term it has to spawn off a new version that escapes the frozen
status, so improvements can be made. If there is a substantial
reason to move to eTeX in the long term it may very well be implemented
in the commercial versions also eventually. Or perhaps by that time
the web source will support dynamic allocations for most of TeX's fixed
spaces, and many of the other minor improvements.
If we look this far ahead, getting through the encoding morass is a critical
issue. And a derivative of UNICODE may help here. While I admire the
Omega tour de force (see the very appropriate image on their web site),
I am not sure that is the way to go.
>And it does support running in full
>compatible mode meaning that there is virtually no difference between
>etex and TeX in that mode.
Berthold.
*****************************************************************************
Y&Y, Inc. `Acrobat-ready PS from TeX'
(see http://www.YandY.com/pdf_from.pdf)
45 Walden Street, Concord, MA 01742 USA
Phone: (800) 742-4059 (North America only)
Phone: (978) 371-3286 Fax: (978) 371-2004
----------------------------------------------------------------------------
-----------------
Sales: mailto:sales@YandY.com
Support: mailto:support@YandY.com
Site License: mailto:main-office@YandY.com
----------------------------------------------------------------------------
----------------
World Wide Web: http://www.YandY.com
*****************************************************************************