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