777531 - SVGLocatable.getTransformToElement() returns incorrect transformation matrix

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Martin Hejral]

Attachment: .getTransformToElement() calculation example

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

Example of SVG structure:

<svg viewBox='0 -200 200 200' x='0' y='0' width='800' height='800'>
...
<text id='text1'>...</text>
...
</svg> 




Actual results:

In this example is returned:
* TRANSFORMATION MATRIX: 0.5, 0, 0, 0.5, 0, 0; from current=svg to -> text

See:
http://www.w3.org/TR/SVG/types.html#InterfaceSVGLocatable
current.getTransformToElement(element);
* Returns the transformation matrix from the user coordinate system on the current element to the user coordinate system on parameter element


Expected results:

I think that correct is WEBKIT, which returns:
* TRANSFORMATION MATRIX: 4, 0, 0, 4, 0, 800; from current=svg to -> text

Also Opera and FireFox are WRONG!

Comment 1

[Robert Longson [:longsonr]]

FWIW Batik agrees with Opera and Firefox. Perhaps you could explain in more detail why you think webkit is right?

Comment 2

[Martin Hejral]

(In reply to Robert Longson from comment #1)
> FWIW Batik agrees with Opera and Firefox. Perhaps you could explain in more
> detail why you think webkit is right?

Robert, I made a new more detailed tests to precise the problem. It shows also screenCTM and matrix computing at different nested coordinate levels...

I am sorry for my first description, it was a little rush out. We work with complicated nested SVG structures. Detailed test shows that every browser has its own problem, but at different places... which is too confusing :-( 

Please check my results in next attachments. thank you.

Comment 3

[Martin Hejral]

Attachment: complex calculation test (output to the console)

it seems that the only problem is calculation in svg#level2 node:

getTransformToElement MATRIX: 0.5, 0, 0, 0.5, -1, -5; point [100,100] in baseNode#level0 coordinate system -> transformed to svg#level2 coordinate system [49,45] !!BUG

correct should be:
MATRIX: 1, 0, 0, 1, -2, -10;

Comment 4

[Martin Hejral]

Attachment: test results for FF, Chrome and Opera

TEST OUTPUT:

-------------------
FF 17.0a1 (2012-08-09) / Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Firefox/17.0
-------------------

LEVEL0
getScreenCTM(): 5, 0, 0, 5, 0, 0; svg#level0 coordinate system
 getTransformToElement MATRIX: 1, 0, 0, 1, 0, 0; 
getScreenCTM(): 5, 0, 0, 5, 0, 0; rect#level0rect coordinate system 
 getTransformToElement MATRIX: 1, 0, 0, 1, 0, 0; 

LEVEL1
getScreenCTM(): 10, 0, 0, 10, 10, 50; g#level1 coordinate system
 getTransformToElement MATRIX: 0.5, 0, 0, 0.5, -1, -5;
getScreenCTM(): 10, 0, 0, 10, 10, 50; rect#level1rect coordinate system 
 getTransformToElement MATRIX: 0.5, 0, 0, 0.5, -1, -5;
getScreenCTM(): 10, 0, 0, 10, 10, 50; text#level1text coordinate system
 getTransformToElement MATRIX: 0.5, 0, 0, 0.5, -1, -5; 

LEVEL2
===>getScreenCTM(): 10, 0, 0, 10, 10, 50; svg#level2 coordinate system !!BUG
===> getTransformToElement MATRIX: 0.5, 0, 0, 0.5, -1, -5; !!BUG
getScreenCTM(): 5, 0, 0, 5, 10, 50; rect#level2rect coordinate system
 getTransformToElement MATRIX: 1, 0, 0, 1, -2, -10;

Comment 5

[Robert Longson [:longsonr]]

Perhaps you could explain why you think 1, 0, 0, 1, -2, -10 is the right answer?

Comment 6

[Robert Longson [:longsonr]]

And do check out bug 780169 as that issue seems similar.

Comment 7

[Robert Longson [:longsonr]]

The level2 svg element has a viewBox which transforms where its children go but does not affect where the svg element itself is positioned.

Comment 8

[Martin Hejral]

(In reply to Robert Longson from comment #7)

At first I checked bug 780169
Correct, this is the same problem :-(

> The level2 svg element has a viewBox which transforms where its children go
> but does not affect where the svg element itself is positioned.

Robert, sorry for slow reaction -- I spend too many time with this problem already ...to find strange problem in our app, analyze and think over and over again... it is really essential question for any SVG app for now a for future... please one more analysis with clear head.

As I see this case -- the fundamental question is -- whether to include transforms caused by a <svg> element on this element itself?

Do you agree with this?



I have many arguments for 1st version -- including transforms for <svg> elm. itself

/1/ back to the root -- specification:

SVGMatrix getScreenCTM()
    Returns the transformation matrix from current user units (i.e., after application of the ‘transform’ attribute, if any) to the parent user agent's notice of a "pixel". 

SVGMatrix getTransformToElement(in SVGElement element)
    Returns the transformation matrix from the user coordinate system on the current element (after application of the ‘transform’ attribute, if any) to the user coordinate system on parameter element (after application of its ‘transform’ attribute, if any). 

I must to EMPHASIZE and ACCENT this: (after application of the ‘transform’ attribute, if any)!

I know, there is NO ‘transform’ attribute, but... we must treat viewbox+size of nested SVG as transform!



/2/ we need this for CONSISTENCY!!

By my opinion it is necessary to work with <svg> in the same way as with <g transform=...>

Influence of <svg> for transformation matrix and current user units is exactly the SAME!! (not rendered, only container for other objects!)

This is why I in (comment 4) divide test output to 3 groups marked as: LEVEL0-2

Any object on the same level of user units must have the same getScreenCTM() + getTransformToElement(). Do you agree?



/3/ suppose that FF14 is right (but I do not believe), then you get inconsistency for getTransformToElement(), e.g.

LEVEL0
getScreenCTM(): 5, 0, 0, 5, 0, 0; //in svg#level0
getTransformToElement MATRIX: 1, 0, 0, 1, 0, 0; //svg#level0 -> svg#level0

getScreenCTM(): 5, 0, 0, 5, 0, 0; //in rect#level0rect
getTransformToElement MATRIX: 1, 0, 0, 1, 0, 0; //svg#level0 -> rect#level0rect

LEVEL2
===>getScreenCTM(): 10, 0, 0, 10, 10, 50; //svg#level2
===>getTransformToElement MATRIX: 0.5, 0, 0, 0.5, -1, -5; //svg#level0 -> svg#level2

getScreenCTM(): 5, 0, 0, 5, 10, 50; //rect#level2rect
getTransformToElement MATRIX: 1, 0, 0, 1, -2, -10; //svg#level0 -> rect#level2rect


AND now, what result should have getTransformToElement() from svg#level2 -> to rect#level2rect?

????

PLEASE, think about it again. Thanks for attention.

Comment 9

[Robert Longson [:longsonr]]

http://www.w3.org/TR/SVG/coords.html#TransformAttributeEffectOnSiblingAttributes

vs

http://www.w3.org/TR/SVG/coords.html#ViewBoxAttributeEffectOnSiblingAttributes

See how transform affects the co-ordinates of the element itself but viewBox doesn't

Comment 10

[Robert Longson [:longsonr]]

Also the gecko getTransformToElement is consistent with getScreenCTM as getTransformToElement is implemented by calling getScreenCTM. See http://dxr.mozilla.org/mozilla-central/content/svg/content/src/nsSVGSVGElement.cpp.html#l692

Comment 11

[Martin Hejral]

(In reply to Robert Longson from comment #9)
> http://www.w3.org/TR/SVG/coords.
> html#TransformAttributeEffectOnSiblingAttributes
> 
> vs
> 
> http://www.w3.org/TR/SVG/coords.
> html#ViewBoxAttributeEffectOnSiblingAttributes
> 
> See how transform affects the co-ordinates of the element itself but viewBox doesn't

Robert thanks for the links, I probably understand what you mean. 

...OK: "transformation that is created due to a ‘viewBox’ does not affect the ‘x’, ‘y’, ‘width’ and ‘height’ attributes..." OK...however this is NOT relevant for our problem!!

...BUT what IS relevant is this text: "On the other hand, like the ‘transform’ attribute, it does establish a new coordinate system for *all* *other* *attributes* and for descendant elements." 

This IS IMPORTANT: all other!

As a result we can probably say -- TRANSFORMATION MATRIX computing should behave in the same way as with ‘transform’ attribute -- which is CONSISTENCY I meant...

Comment 12

[Martin Hejral]

(In reply to Robert Longson from comment #10)
> Also the gecko getTransformToElement is consistent with getScreenCTM as
> getTransformToElement is implemented by calling getScreenCTM. See
> http://dxr.mozilla.org/mozilla-central/content/svg/content/src/
> nsSVGSVGElement.cpp.html#l692

OK, but I meant geometric and mathematical consistency... 

...currently FF 17.0a1 (2012-08-15) compute:

getTransformToElement() from svg#level2 coordinate system -> to rect#level2rect coordinate system

with this result MATRIX: 2, 0, 0, 2, 0, 0;

Do you think IS THIS CORRECT? Both elements are in the SAME coordinate system...

Comment 13

[Martin Hejral]

(In reply to Martin Hejral from comment #12)
> (In reply to Robert Longson from comment #10)

> ...currently FF 17.0a1 (2012-08-15) compute:
> 
> getTransformToElement() from svg#level2 coordinate system -> to
> rect#level2rect coordinate system
> with this result MATRIX: 2, 0, 0, 2, 0, 0;

also computing

getTransformToElement() from svg#level0 coordinate system -> to
rect#level0rect coordinate system

ends with result MATRIX: 1, 0, 0, 1, 0, 0;

THIS IS INCONSISTENCY!

Comment 14

[Robert Longson [:longsonr]]

I suggest you raise this with the w3c svg working group. The specification would benefit from a clear definition of what to do.