Re: [SVG] assigning to currentScale

Hi Chris,

Chris Lilley wrote:
> On Sunday, September 18, 2005, 10:40:24 PM, Jonathan wrote:
> 
> JW> SVG WG,
> 
> JW> Since the implementation of SVG events in Firefox it has become apparent
> JW> that it's necessary for us to restrict the range of values that we allow
> JW> to be assigned to currentScale (for various reasons).
> 
> What reasons, beyond the 'ASV does it' one below?

I wasn't using that as a reason, I was pointing out that we aren't the 
only implementation that has encountered this issue.

The main reason for us would be that zooming in too far results in the 
CPU maxing out and the whole UI freezing up. Zooming out too far results 
in entirely incorrect nonsense rendering to the screen. Whatever the 
reason for the lockup when zooming in, there's no time for us to 
investigate and correct this the "right" way (if indeed there is one) 
before our next release. If the problem turns out to be in GDI+ our 
hands are tied anyway. I think the spec should allow for implementations 
having to clamp currentScale.

> The viewer should not limit the scale.
> 
> I have had cases where I had to set a particular initial view on an SVG
> document, just because ASV did not allow me to zoom far enough in to see
> everything if the initial view covered the entire graphic.

I agree we don't *want* to do this, but we're going to need to.

> I don't see anything in the spec that supports limiting the
> zoom range.

There isn't. It assumes it's unlimited, but that's not practical for us.

> JW> On a related note, what should happen when zoomAndPan="disable" and an 
> JW> attempt is made to assign to currentScale?
> 
> Hmm, depends on whether zoomAndPan="disable" disables the user zoom
> controls or disables zooming. I believe it disables the controls, so
> zooming via script should still work. Indeed, i think the main reason
> people use zoomAndPan="disable" is so that they can give a more
> context-sensitive zoom interface in script (eg a map panner with a
> thumbnail).

I see, thanks. It might be worth a note in the errata and new specs that 
makes this explicit.

On a related note, what happens when the UI limits the values that can 
be assigned to currentTranslate.x and .y? Again I guess your answer is 
"it shouldn't". As I understand it, as I'd like it to function, and as a 
lot of SVG out there assumes, it shouldn't. However, the spec doesn't 
make it clear that this is the case either for scripts or the UA's 
controls. Argument over this has been the reason I haven't implemented 
zoom and pan controls for Firefox yet. Those in control of the Firefox 
UI want us to use the controls already familiar to users for panning, 
namely scrollbars. Inherent to scrollbars is the idea of limits. If we 
use scrollbars it also doesn't make sense to allow scripts to assign any 
value to currentTranslate.x and .y.

We need the WG to consider what the "width" and "height" of an SVG 
document really is. Is the area enclosed within {x, y, width, height} 
the intrinsic size of the SVG and thus the area that the implementation 
should limit panning to? Or should it be the BBox of all content in the 
SVG (again limits being applicable)? (Those are the two proposals 
currently semi-acceptable to the Firefox UI controllers.) I hope this 
can all be sorted out in SVGMobile12, but note we'll also need an errata 
item for SVG 1.1 before the mess that is Firefox's scrolling/zooming and 
panning can be sorted out.

Regards,
Jonathan

Received on Monday, 19 September 2005 16:23:01 UTC