Bug 5240 – WebKit+SVG does not always display <use> tags correctly.

• Component: SVG
• Status: RESOLVED FIXED

[Tobin Richard]

This is possibly a KSVG problem.

Some SVG images appear incomplete when displayed using Safari+SVG (latest build
from 2005-09-03).

Example 1: http://openclipart.org/clipart//computer/cpu_heatsink_fan_socket_.svg
should look like
http://openclipart.org/clipart//computer/cpu_heatsink_fan_socket_.png (note
missing side)

Example 2:
http://openclipart.org/clipart//unsorted/newspaper_aubanel_monnie_01.svg should
look like
http://openclipart.org/clipart//unsorted/newspaper_aubanel_monnie_01.png (note
missing text)

[Eric Seidel (no email)]

The missing text is caused by:
http://bugzilla.opendarwin.org/show_bug.cgi?id=4883

The first example seems to be something else.  Not sure yet.

[Julien Palmas]

Created attachment 4212 [details]
Reduced example

The problem comes from the <use> tag.

[Eric Seidel (no email)]

This may have been related to memory fixes I made to KSVG::StyledElementImpl::attach()

            if (parentElement && parentElement->isStyled())
                    styledParent = static_cast<SVGStyledElementImpl *>(parentElement);
            if(styledParent && styledParent->canvasItem() && styledParent->allowAttachChildren(this))
                styledParent->canvasItem()->appendItem(m_canvasItem);
            else if (styledParent && (styledParent->id() != ID_PATTERN)) {
                // FIXME: This exists until we can find a better way to create root && pattern nodes. -- ecs 
8/7/05
                delete m_canvasItem;
                m_canvasItem = NULL;
                //fprintf(stderr, "FAILED CANVAS INSERTION: <%s>\n", KDOM::DOMString(nodeName
()).string().ascii())
            }

Then again, it may not be related to that at all, since <use> shouldnt' have any children in this 
example.  We would have to talk with rwlbuis or WildFox to make sure.

It might also be worth checking this SVG in DrawTest (where you can scroll around), or reducing it 
further to not have such complicated transforms.  It's possible we're actually still drawing the <use> 
content, but outside the visible region.  I know we have some transformation bugs, possibly in <use> 
content too.

[Julien Palmas]

Created attachment 4218 [details]
same file, but line 2 and 3 have been inverted. Working now

Actually, the <use> element works, but it needs to be written after the
reference element declaration in the source code.

Working example :
<rect width="10" height="10" fill="blue" id="myrect">
<use x="20" y="30" xlink:href="#myrect"/>

Wrong example :
<use x="20" y="30" xlink:href="#myrect"/>
<rect width="10" height="10" fill="blue" id="myrect">

[Rob Buis]

First, a good bug find! 
I think the second example is not a <use> problem, but just 
indicating missing text support. Lets not make this all more 
complex than needed ;) 
I'll attach my current solution soon. 
Cheers, 
 
Rob. 

[Rob Buis]

Created attachment 4221 [details]
Handle <use> that forward references

[Rob Buis]

Created attachment 4229 [details]
Handle forward references correctly

A cleaned up version.

[Julien Palmas]

Created attachment 4231 [details]
Only one out of 2 <use> tags are rendered

Patch 4229 solved the first reduced example, but this new example is still not
rendered correctly.

[Julien Palmas]

Created attachment 4232 [details]
Expected result

[Eric Seidel (no email)]

Comment on attachment 4229 [details]
Handle forward references correctly

Looks good.  I made one small modification (moved the remove() out when doing
the delayed close, and instead added a clear() after all the closes).  I'll
post my fixed patch and land.

[Eric Seidel (no email)]

Created attachment 4253 [details]
Final patch which I landed.