[Prev][Next][Index][Thread]
MMML questions: line breaking, stretchables,...

To: wwwmath@w3.org

Subject: MMML questions: line breaking, stretchables,...

From: Thore Husfeldt <thore@brics.dk>

Date: Wed, 11 Jun 1997 16:44:16 +0200 (MET DST)

From wwwmathrequest@www10.w3.org Wed Jun 11 10: 44:20 1997
Some questions after my first reading of the draft from 15 May 1997.
Line breaking

I realise that many line breaking issues are a subject for the
renderer and not the language, but I am slightly confused by the
meaning of <MROW>. Does the draft inted that that indeed objects
inside an MROW container are to be horizontally grouped in the sense
that line breaking is forbidden? In that case the examples are badly
chosen since I would certainly expect an inline expression like 2x + y
 z to be broken (like here). Please clarify.
There are more issues here, like the breaking and alignment of
multiline formulas that don't seem to be covered.
Fences, fractions

The description vertical stretching rules of fences and big operators
is overly simplistic, especially for the latter; the two should not be
treated as the same thing. For example, much modern mathematical
typesetting sticks to only one integral size, even though brackets are
stretched all the time.
For more comlicated issues, read Rule 21 of The Printing of
Mathematics (Chaundy et al., Oxford 1954): e.g., when two integral
signs (over subexpressions of different height) appear on the same
line, the largest integral sign is to be used througout that line.
A similar rule applies to fractions, which should appear in the same
size (style) on the same line.
These are basically UA issues and reflect different styles of
mathematical typesetting, but the draft shouldn't enforce bad
rendering by mentioning simplistic rules.
Numbers

Do the examples indicate that <MN>1,500</MN> always stands for
onethousandfivehundreds and never for oneandahalf? This would be
rather awkward for other languages than English. This issue seems to
cross the presentationcontent division in some strange way.
Comments are welcome,
Thore Husfeldt
thore@brics.dk