308117 - SVG: setting currentScale does no longer result in changing the presentation of the svg element

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[thomas]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050911 Firefox/1.6a1

With Deer Park Alpha 2, setting the currentScale property of a svg element
resulted in Deer Park zooming in/out the svg image. Since Firefox 1.5 Beta 1
setting currentScale does no longer affect the element presentation.

I hope, that this behavior is easy to fix, as I have written a planing tool
(using svg for the gui) that relys heavily on the ability to zoom in an out of a
svg image. Would be nice to see this working again in the final Firefox 1.5 version.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.gleiss-leeb.at/foryou/svgtest.xml
2. Play with the + and - Buttons


Actual Results:  
With Deer Park Alpha 1 or 2: the triangle gets bigger, if you click on the +
button and smaller, if you click on the - button

With Firefox 1.5 Beta 1: no visible change of the svg content (but the
currentScale property is set correctly)

Expected Results:  
Firefox 1.5 Beta 1 should behave like Deer Park and change the size of the svg
content according to the value of currentScale, providing an easy way of zooming
into the image - after all, this is the 'scaleable' in scaleable vector graphics.

Comment 1

[PikeUK]

-> Core:SVG

Comment 2

[Jonathan Watt [:jwatt]]

We are now deliberately only paying attention to the values of currentScale and
currentTranslate on 'svg' elements that are the document (root) element. In
other words zooming and panning can only be done at a document level. The
properties currentScale and currentTranslate are really intended for the use of
the user agent. If you want to provide your own zoom and pan controls for a sub
part of a document you'll need to implement your own. I've modified your example
to do just this, and I'll attach it shortly. I've also added in a function to
set the translation (pan) of the document for good measure.

Comment 3

[Jonathan Watt [:jwatt]]

Attachment: example

Comment 4

[Robert Claypool]

Why is functionality being removed here? What does the user agent do with these
values?

Comment 5

[Jonathan Watt [:jwatt]]

It's being removed because the specification indicates that currentScale and
currentTranslate are ignored on inner 'svg' elements in SVG content.

"Magnification represents a complete, uniform transformation on an SVG document
fragment, where the magnify operation scales all graphical elements by the same
amount. A magnify operation has the effect of a supplemental scale and translate
transformation placed at the *outermost* level on the SVG document fragment
(i.e., outside the outermost 'svg' element)."

(emphesis mine) and

"If a zoomAndPan attribute is assigned to an *inner* 'svg'  element, the
zoomAndPan setting on the inner 'svg' element will have no effect on the SVG
user agent."

(emphesis mine) and

"float currentScale
    This attribute indicates the current scale factor relative to the initial
view to take into account user magnification and panning operations, as
described under Magnification and panning. DOM attributes currentScale and
currentTranslate are equivalent to the 2x3 matrix [a b c d e f] = [currentScale
0 0 currentScale currentTranslate.x currentTranslate.y]. If "magnification" is
enabled (i.e., zoomAndPan="magnify"), then the effect is as if an extra
transformation were placed at the *outermost* level on the SVG document fragment
(i.e., outside the outermost 'svg' element)."

(emphesis mine) and

"readonly SVGPoint currentTranslate
    The corresponding translation factor that takes into account user
"magnification"."

Although it doesn't specify how currentScale and currentTranslate should be
treated on non-document element 'svg' elements in compound documents, to be
consistant we are now ignoring them in this case pending clarification by the
SVG WG. While we can decide to ignore them now and add support in future if the
WG so decides, the opposite is not true. Additionally, as I've shown, it's not
difficult to get what you want using transforms.