Re: SVG: tspan

On Tue, 01 May 2012 21:47:03 +0200, Christina Roßmanith  
<ChrRossmanith@gmx.de> wrote:

> Hi,
>
> consider the following SVG example:
>
> <svg><text><tspan>q</tspan></text></svg>
>
> which is rendered blank instead of showing the letter 'q'.
>
> <tspan> prevents q being added to sText here (svgreader.cxx):
>
> visitChildren(boost::bind(
>                                    (rtl::OUStringBuffer&
> (rtl::OUStringBuffer::*)(const rtl::OUString&
> str))&rtl::OUStringBuffer::append,
>                                    boost::ref(sText),
> boost::bind(&xml::dom::XNode::getNodeValue,
>                                                _1)),
>                                xElem,
>                                xml::dom::NodeType_TEXT_NODE);
>
> In visitChildren() an output of getNodeValue() shows that <tspan> has an
> empty value. Who is responsible for that??? I'd expect a value "q". Node
> type is NodeType_ELEMENT_NODE. Is that what is expected? Or should
> <tspan> and <text> both be treated as NodeType_TEXT_NODE?

Hi Christina,
well first off a word about node types:
xml elements (that is tags) are always nodes of type ELEMENT_NODE,
sequence of characters are nodes of type TEXT_NODE.
So in the following example:
<text>svg<tspan>import</tspan>filter</text>

the DOM structure is as follow:
ELEMENT_NODE(<text>)
|
+--TEXT_NODE("svg")
|
+--ELEMENT_NODE(<tspan>)
|  |
|  +--TEXT_NODE("import")
|
+--TEXT_NODE("filter")


The problem is that the XML_TEXT case 'believes' to have to handle
only nodes of type TEXT_NODE as children.

Indeed it is not so simple handling nested <tspan> elements
because the placement of a <tspan> element have to take into account
the length of the preceding text, when it does not define its own
'x' attribute:
<tspan>.x = <text>.x + length("svg")
where length("svg") has to take into account all the font properties
and transformations applied to <text>, and this is only the case
for horizontal text.

In the following case:
<text>svg<tspan x="100">import</tspan>filter</text>

the svg standard says that "filter" needs to be placed at
x = <tspan>.x + length("import")
again all style properties and transformations applied
to <tspan> have to be taken into account for evaluating the text
length.

So importing text correctly needs a good amount of work.
I hope at least to have spread a bit of light in the right direction.

Reference: http://www.w3.org/TR/SVG11/text.html#TSpanElement

-- Marco


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/