W3C home > Mailing lists > Public > www-math@w3.org > June 2007

RE: linebreaking mathml

From: Neil Soiffer <neils@dessci.com>
Date: Wed, 6 Jun 2007 15:44:47 -0700
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD601EAD98F@franklin.corp.dessci>
To: <www-math@w3.org>

Not that any user agent pays attention to it, but the <math> element
does have the "overflow" attribute.  From the spec:

In cases where size negotiation is not possible or fails (for example in
the case of an extremely long equation), this attribute is provided to
suggest an alternative processing method to the renderer. Allowed values

	The window provides a viewport into the larger complete display
of the mathematical expression. Horizontal or vertical scrollbars are
added to the window as necessary to allow the viewport to be moved to a
different position. 

	The display is abbreviated by removing enough of it so that the
remainder fits into the window. For example, a large polynomial might
have the first and last terms displayed with "+ ... +" between them.
Advanced renderers may provide a facility to zoom in on elided areas. 

	The display is abbreviated by simply truncating it at the right
and bottom borders. It is recommended that some indication of truncation
is made to the viewer. 

	The fonts used to display the mathematical expression are chosen
so that the full expression fits in the window. Note that this only
happens if the expression is too large. In the case of a window larger
than necessary, the expression is shown at its normal size within the
larger window. 

This doesn't specifically say "don't linewrap", but it is close.  It
does seem like it should be taken into account by any mechanism that
gets developed, although I don't see developing a mechanism as a burning
need.  I think it is more important to encourage auto linebreaking in

Neil Soiffer
Senior Scientist
Design Science, Inc.
~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~

-----Original Message-----
From: www-math-request@w3.org [mailto:www-math-request@w3.org] On Behalf
Of Robert Miner
Sent: Wednesday, June 06, 2007 3:19 PM
To: www-math@w3.org
Subject: RE: linebreaking mathml

You raise a reasonable point.  While the CSS nowrap directive is
probably a reasonable solution in Web contexts, it seems like there
should be a way of disabling line breaking in MathML in non-CSS


Robert Miner
Director, New Product Development

Design Science, Inc.
140 Pine Avenue, 4th Floor
Long Beach, California  90802
Tel:  (651) 223-2883
Fax:  (651) 292-0014
~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor,
TexAide ~

> -----Original Message-----
> From: www-math-request@w3.org [mailto:www-math-request@w3.org] On
> Of William F Hammond
> Sent: Wednesday, June 06, 2007 12:17 PM
> To: www-math@w3.org
> Subject: Re: linebreaking mathml
> Hi Bruce,
> You write on an issue concerning presentation MathML in web browsers:
> >   I suppose that when MathML was originally developed, the authors
> > imagined that the browser would be responsible for line breaking. 
> > ...
> I am concerned with the community of authors having TeX backgrounds.
> As one such author I want complete control over linebreaks in math.
> I believe this is the general attitude among TeX users for traditional
> print.
> I want to emulate that as much as possible in XHTML+MathML.
> Accordingly for all <math> elements I set the "white-space" CSS
> property to "nowrap".  For examples such as you suggest I use <mtable>
> with no more than 3 cells per row as the sole content of <math> in
> display mode.  When there is insufficient width of the user's browser,
> the window will require horizontal scrolling.
> As author I limit the width of content so that the need for horizontal
> scrolling should not arise with a font of default size in a browser
> window that is 60% of the width of a 1280x1024 display.
> The width limitation is natural when I am using one source markup for
> both XHTML+MathML and print (via LaTeX).
>                                     -- Bill
Received on Wednesday, 6 June 2007 22:45:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:39 UTC