Re: line-b reaking-algorithm [was: Re: [CSSWG] Minutes Telecon 2013-04-10]

On 2013-04-10, at 10:36 PM, Liam R E Quin <liam@w3.org<mailto:liam@w3.org>> wrote:

On Wed, 2013-04-10 at 22:11 -0400, Zack Weinberg wrote:
On Wed, Apr 10, 2013 at 9:19 PM, fantasai <fantasai.lists@inkedblade.net<mailto:fantasai.lists@inkedblade.net>> wrote:
 liam: This proposal is to let an author/script say "this piece of text
       is going to be interactively edited"...
 liam: I imagine a print processor would set this to "batch" - not edited.
 liam: You care about editted or not because if you insert a word in the
       middle of a paragraph, and you use a multi-line linebreaking algo,
       your text will reflow and your insertion point might move up or
       down a line.
 liam: Some programs handle this by only reflowing when you finish editing,
       but it's ugly in the meantime.  It's a problem with a long history.
 liam: Two parts of this proposal:
 liam: 1) Say your intent, interactive or batch.
 liam: 2) Second, experimentally, say what algorithm to use.
...

I just want to say here that I think it's very important that whatever
happens in this area, renderers are allowed to apply higher-quality
linebreaking algorithms to documents *without* authors having to opt
in.

I agree strongly - my suggestion was (and remains) to make the default
implementation dependent. The goal is to make it easier for browsers &
CSS formatters to experiment with higher quality line-breaking
algorithms, such as n-line, but to provide a mechanism (as you say) for
preventing possible problems.

I'd go for that. eReaders will likely want to go for the best typography everywhere possible, and would thus define 'auto' as the 'bug fixed TeX' algorithm on any device that will support it. We don't need to worry about reflowing that much, after all :o)
_________________________________________
Jim Dovey
Digital Content Format Evangelist | Kobo Inc.
jdovey@kobo.com<mailto:jdovey@kobo.com>
C: (416) 716-0413
135 Liberty St. | Suite 101 | Toronto, ON  | M6K 1A7

[cid:image001.png@01CD8762.BDA95B70]

Received on Monday, 15 April 2013 13:21:48 UTC