I don't think anyone is proposing to use the math brace pieces directly in
MathML or in any other higher-level representation of math. Their purpose
is for drawing large brackets, braces, integrals, etc., on print/display
devices, not for encoding in the original documents themselves. This
display use ties in with your stylesheet proposal: the math rendering engine
outputs the various pieces that make up the large character desired.
Note that using scalable font technology for large braces, e.g., a 30-pt
left curly brace, produces a brace with lines that are too thick, too bold.
You need to use the brace pieces, replicating the vertical extensions as
necessary, to get a good looking large brace. You can see what's done in
the industry by examining standard math, physics, chemistry, etc., journals
in your nearest university library (or by looking at your technical
textbooks). The brace pieces appear in many existing character sets,
notably in the PostScript symbol set, the HP Math8 symbol set, various
terminal symbol sets, in the Windows symbol font, as well as in the STIX
proposal. If you're interested in the current Unicode proposal, pls send me
mail off line.
Thanks
Murray
> -----Original Message-----
> From: Markus Kuhn [SMTP:Markus.Kuhn@cl.cam.ac.uk]
> Sent: Tuesday, November 30, 1999 3:58 AM
> To: Unicode List
> Cc: Unicode List; mozilla-mathml@mozilla.org
> Subject: Math glyph fragments considered harmful
>
> 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