[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: defining the script sizes via font dimens


Berthold,

 > >PS.: And what about the new font dimensions for math spacing (ie \thinmuskip
 > >and friends) ? Has anybody experiences with customizing those values ? Should
 > >we expect them to vary between font families ?
 > 
 > I think there is an endless reservoir of things one could put in.  
 > In CM several quite different things are tied into one parameter. For example,

i agree that they are endless in theory but i don't think they are
endless in practise.

 > the defaultrulethickness is used for several different spacing purposes that
 > lead to conflict and compromised in fonts other than CM (particularly
 > w.r.t radicals and fractions and limits).   Then, the assumption
 > is made that various `axes' are all at the same height (as they are in CM).
 > This again leads to problems in non-CM fonts (e.g. the operator `axis'
 > need not be the same as the delimiter `axis' --- and isn't in Lucida New
 > Math).
 > 
 > One could imagine adding more font dimensions to deal with some of this,
 > but it is probably pointless since it is the hard-wired TeX math typesetting
 > machinery that ought to look at these new parameters and use them...


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)

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. And it does support running in full
compatible mode meaning that there is virtually no difference between
etex and TeX in that mode.

frank