W3C home > Mailing lists > Public > www-style@w3.org > March 2013

[css-text3] line breaking - interactive vs. batch

From: Liam R E Quin <liam@w3.org>
Date: Fri, 08 Mar 2013 17:15:29 -0500
To: www-style list <www-style@w3.org>
Message-ID: <1362780929.9148.257.camel@localhost.localdomain>
A proposal to add two properties to give control over the line-breaking
algorithm (or two aspects of a single algorithm):
(1) choice of intent - interactive or batch
(2) specify which algorithm to use and supply parameters to it
It'd probably be OK just to do (1) for now and see what happens.

This is to let browsers and formatters experiment with different
line-breaking algorithms in ways that don't break interactive behaviour.


Rationale

A line-breaking algorithm generally splits the input into chunks called
"words", and puts as many words as will fit on each line. This is known
as a first-fit algorithm.  First-fit algorithms tend to leave unsightly
uneven margins, or distracting holes in the text, especially when the
measure (line-length) is less than 20en (10em) or so.

For an interactive formatter, such as a Web browser, an important
property of a line breaking algorithm is that adding text does not
make the insertion point move about. For example, a TeX-style
Knuth-Plass dynamic programming algorithm will sometimes rearrange an
entire paragraph if a single word changes, making it unsuitable for
editing (and for progressive rendering).

The best compromise is usually an "n-line forward shuffle," as used
in some commercial software: it is best fit, except that if after
filling a line the algorithm finds the line is not very full, words
(or partial words if hyphenation of word-breaking is used) are taken
from the previous line and added to the current line to average out
the amount of text on each line - the line length or, if justified, the
space size. It's easy to implement this in a way that does not affect a
"current line", and it does not significantly slow down progressive
rendering. An n-line variant is used in commercial products today.

Note that high quality justification does not normally alter letter
spacing or character fit, although experiments have been done with
expanding or contracting the letter-forms very slightly. The reason
for this is partly that letter spacing destroys the natural rhythm of
the letter-forms and can disrupt reading and comprehension, and partly
that some languages (most notably German) use letter-spacing for
emphasis.


Proposal:

Two new properties to control line breaking. One to let the formatter
know whether line-breaking is to be optimized for interactive editing
or for reading and legibility, and another to suggest an algorithm
to use, and to pass parameters to that algorithm.

    line-breaking-intent: inherit | default | interactive | legibility |
auto

A value of "auto" lets the user agent decide, and would be a sensible
default. For example, an element marked as editable, or a form input
text area, should use "interactive". However, if a previously static
area of text becomes editable, the user agent should take care not to
reformat entire paragraphs or blocks in a distracting manner.


    line-breaking-algorithm: inherit | default | algoname-list
    algoname-list ::= name [other-stuff] [, algoname-list]

other-stuff is a space-separated list defined by the algorithm.
The first algorithm known to the formatter is used.
Suggested algorithm names:
    best-fit
    n-line
    tex

Most interactive engines will support best-fit and (I hope) n-line;
a print engine will (I hope) support n-line and maybe a TeX derivative
(commercial systems usually modify the TeX algorithm to prevent some of
its worst-case behaviours)

Examples:
    line-breaking-algorithm: n-line 6
    line-breaking-algorithm: tex hyphenation-goodness=0.8, n-line 9,
default

note:
    It would be nice to standardize some values and options but I think
    it's too early.



-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Received on Friday, 8 March 2013 22:15:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT