Erik van der Poel wrote on 1999-11-29 21:38 UTC:
> I don't really know exactly what the STIX project intends to come up
> with, but if other math fonts (e.g. Mathematica's) are any indication,
> then they will presumably include whole glyphs at different sizes within
> a single font (e.g. the square root thingie at various sizes) as well as
> partial glyphs that are supposed to be glued together (e.g. top part,
> straight part, middle part and bottom part of curly braces '{' and '}').
I hope not!
I strongly advise against doing portable mathematical typesetting this
way! Placing square roots of different sizes and bracket fragments that
are to be glued together into a font will create a very tight semanical
bond between the font and the application. This is guaranteed to become
a major obstacle for the free exchangeability of fonts and applications
and only works in practice if you get the application and the fonts from
the one and same developer (as you do with TeX and Mathematica). TeX
(which is de-facto almost exclusively used with only the Computer Modern
fonts!) has set a very bad precedent here, which we should see as an
opportunity to learn from, how to do it better, and not to copy it
blindly.
There is a conceptually much neater and cleaner solution:
If you want your typesetting system to be strong enough to support the
mathematical notation, then include in the style-sheet language (CSS,
DSSSL, XSL, whatever) a small and simple functional programming language
and graphical primitives, such that style-sheet designers can write
algorithms for plotting beautiful variable-size brackets and
square-roots and do not have to depend on the fragments they find in the
fonts.
Stop seeing variable-size annotations of mathematical formulae as
characters, but start treating them as what they really are: graphical
ornaments composed of graphical primitives (line strokes, polygons,
arcs, splines, etc.), just like the rules in a table or other page
layout features.
Adding small graphics algorithms for plotting calculated objects to a
style-sheet language has many advantages:
- The existing Unicode 3.0 repertoire will be sufficient for most
mathematical publishing needs.
- Arbitrary existing fonts can be used to do mathematical typesetting,
you do not have to know any more, what the designer was planning
exactly for the bracket fragments and their detailed alignment
properties.
- Algorithmically calculated square roots will lead to more satisfactory
results than those plugged together from a small number of
ready-made components.
- The trickier aspects of mathematical typesetting become handled
by a powerful universal mechanism in the style sheet language
that has no intrinsic dependencies on the current fashions of
19th and 20th century mathematics. It will be able grow with the
field and will also cover other scientific graphical notations
(chemistry, may be even music). All that has to be changed are the
application-dependent style sheets, not the base standards.
One of the big practical problems with TeX was always, that TeX only
works well with fonts that were specifically designed for it, because
(especially for the math symbol fragments), TeX makes a lot of detail
assumptions about the precise shapes of the glyphs. TeX's major flaw is
the lack of any more powerful graphical primitives than horizontal and
vertical rules that could be used in its macro language. TeX users have
to struggle with hacks such as special-purpose fonts and embedded
Postscript files every day to work around the limitations that were
probably only motivated the limitations of Knuth's original 1970s
phototypesetter.
You break a neat modularization boundary in a typesetting system, if you
move graphical style elements into the glyph repertoire of the font.
I hate to see the same mistakes made by TeX being repeated in MathML
implementations and other more modern mathematical typesetting systems.
Markus
-- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT