On Wed, 2004-11-03 at 19:25, Ian Hickson wrote:

...

• do you believe UAX 14 addresses the needs for automatic line breaking? (eg. interoperability, CSS not available, internationalised text support)

UAX 14 is woefully inadequate for describing required line breaking behaviour. Requiring UAX 14 compliance dramantically restricts the ability for user agents to achieve optimum line breaking (as, in fact, UAX 14 itself points out in the introduction), for example it prevents handling of hyphentation and doesn't allow for adaptive balancing justification algorithms.

So no.

Speaking as an SVG authoring tool implementor (Inkscape), the impression I get is that these constraints make SVG's flow facilities relatively useless for much of our user community who want more visually refined breaking algorithms.

For images, I think the better solution would be for word wrapping to be performed at authoring time (possibly using extensions for authoring tools to use so that they can agree on what to wrap around what).

We'd decided to attempt to exactly that approach, though the current implementation is very provisional. It's potentially kind of nasty, but not that bad; it should render identically in all conforming SVG UAs, which was the main goal.

I think I understand the desire the SVG 1.2 flow stuff is trying to address, though; namely text in generated SVG documents where:

* the text can vary greatly in length

This necessitates that at least some layout decisions be made at or after the time the final SVG document is generated -- a prepared static template for layout may not be sufficient.

* the code generating the text might be a simple ECMAScript program or XSLT transform

I've tried implementing basic text flow in XSLT before. It seemed doable (less painfully with sufficiently new revisions of the standard) but it was too much pain and overhead to be done server-side at the time.

Doing flow in ECMAScript on the client-side is another option, but at best means another large hunk of script to suck over the web along with the original document, and does require scripting support.

-and-

* the automatically flowed text should be renderable in any SVG UA (at least one which implements a suitable SVG profile)

Since SVG UAs obviously aren't required to implement anything not specified in the standard, using a separate namespace for flow extensions doesn't provide a very strong interoperability guarantee.

It's easy to imagine a desire for these things on the Web, which I think implies that SVG needs some sort of basic built-in flow capability (even if people adopt other approaches to meet other sets of needs).

-mental