Re: Towards resolution of SVG 1.2 Flowing text

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