Re: SVG12: Text Layout vs Scripting

Bjoern Hoehrmann wrote:

>   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.

    I would agree that this is probably underspecified.

> 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 [...]

    I haven't seen the example but it wouldn't surprise me if the real 
issue is that with nodes of variable size, the complexity of layout
goes through the roof.

> 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) 

     Please _don't_ do this!

> and further that it is possible to achieve this effect without using 
> forceRedraw().

     Please _do_ this!

> 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.

    I'd be curious how you came to this conclusion, because I just
checked Batik and ASV and both of them behave this way (getBBox works
on text that has been dynamically created and inserted into the
document, before any rendering has happened).  In my mind this is the
only reasonable solution.

    What I think is really in need of clarification is when these
methods _don't_ work.  To give my 2 cents I think they shouldn't work
whenever the node is not part of the "rendering tree".  I can think
of tree major cases where this happens:

	1) The node is not part of the document tree (this is
especially problematic as you can't even do proper CSS - if you
support it).

	2) The node is in a 'defs' section, or a symbol.  Some might
argue about this but if something is in the defs section it is
reasonably likely to be referenced by 'use' in which case often
important aspects of the rendering context will shift (like inherited
font).  I think this would also apply to things in a pattern or
clip-path.   Another way of looking at it for me is if some of
it's ancestors don't implement SVGLocatable (defs, symbol, pattern),
then it loses it's locatability.

	3) The node is in a subtree with 'display="none"'.  More
people are likely to argue about this one, but my feeling is that if
you want the element to just be hidden but still part of the rendering
tree then use 'visibility="hidden"'.  People should use display="none"
when they want the rendering system to reclaim any rendering resources
associated with the undisplayed subtree (images, patterns, gradients,
paths, stokes, etc).

> 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.

     I don't see any reason for this.

> 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...

    Well, I'm not sure there is a major issue right now, but I would
agree that some level of clarification might be useful.

Received on Monday, 10 January 2005 11:37:52 UTC