SVG12: Text Layout vs Scripting

Dear Scalable Vector Graphics Working Group,

  From http://www.w3.org/TR/2004/WD-SVG12-20041027/ and any of its
dependencies it seems unclear how text layout interacts with scripting;
in particular, there do not seem to be requirements for implementations
when text layout must be completed such that the various methods on the
SVGTextContentElement and SVGLocatable interfaces work as expected other
than when the text is actually rendered.

It further seems that the only reliable way to bring text elements into
this state from scripts is the forceRedraw() method on the SVGSVGElement
interface; there do not seem to be events that would fire at the very
moment when text layout is completed. forceRedraw() is however not an
appropriate means to realize scripts that depend upon the various means
that depend on completed text layout, calling the method repeatedly can
slow the graphic down, cause unnecessary flicker, or require that text
is made invisible to the user before calling forceRedraw() and made
visible later.

Proper access to the relevant methods is however crucial to a many use
cases where text layout needs to be performed on the client system, e.g.
if data comes from dynamic sources such as those provided through the
new network interfaces; the flowcharting example in the latest sXBL
draft attempts to work around this problem by providing fixed dimensions
for terminalNode and processNode elements which obviously does not scale
very well (in spite of beeing realized using scalable vector graphics)
if the node labels are longer than expected (possibly due to the width
of some glyphs of the font the user agent choosed to render the image).

As the example already demonstrates, this problem will get increasingly
common for sXBL components and in fact in compound document settings,
too, as authors are typically used to flexible layouts such as provided
in XHTML+CSS documents, something like

  <p>foo <span style="border: 4px inset blue">bar</span> baz</p>

is expected to work regardless of fonts and font size settings, once
authors start mixing XHTML+CSS and SVG they will desire this kind of
flexibility in SVG aswell. sXBL and the DOM methods I've mentioned make
this feasible to implement, but only if this does not depend on insane
workarounds that involve lots of forceRedraw calls and messing with
opacity settings or suchlike.

Thus, please change the SVG 1.2 Working Draft such that it is clear that
calling forceRedraw() has the desired effect (text layout for all text
content elements in the document tree is completed and consequently the
text layout depended method calls such as getComputedTextLength() and
getBBox() work as expected) and further that it is possible to achieve
this effect without using forceRedraw().

This can be achieved in several ways, for example, it can be required
that text layout must be performed such that whenever one of the
relevant methods is called for elements in the document tree, it will
return the same result as it would after calling forceRedraw(); this
matches my reading of the SVG 1.1 dependency of the specification but
does not appear to be implemented in SVG 1.0 / 1.1 viewers.

Or new features can be introduced such as a new method on for example
the SVGTextContentElement interface which will cause the user agent to
return a result for the various methods that is indifferent to the
result after calling forceRedraw(). New methods are of course not the 
preferred method of implementing the desired effect.

Further, of course, please include proper test for all the relevant
features in the SVG 1.2 test suite, it seems these are pretty much
untested in the SVG 1.1 test suite -- which seems to explain the root
cause of this issue...

regards.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 7 January 2005 17:39:38 UTC