On Tue, 01 May 2012 21:47:03 +0200, Christina Roßmanith <[email protected]> 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/
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to