Zoom support

[GoogleCodeExporter]

Support for zooming:
Zoom +
Zoom -
Zoom 1:1

see:
http://support.adobe.com/devsup/devsup.nsf/docs/50614.htm
http://snippets.dzone.com/posts/show/5336

Original issue reported on code.google.com by rusn...@gmail.com on 22 Jun 2009 at 12:13

[GoogleCodeExporter]

Pushing this out to 2.4 as I don't think I'll be able to work on it

Original comment by codedr...@gmail.com on 13 Aug 2009 at 4:04

• Added labels: NeededFor-2.4
• Removed labels: NeededFor-2.3

[GoogleCodeExporter]

I'm thinking this would probably be easiest to handle by changing the viewBox 
of the 
root SVG element...except that that would mess things up if the imported file 
has 
that set already. 

Original comment by adeve...@gmail.com on 24 Aug 2009 at 8:29

[GoogleCodeExporter]

Unless someone else really has their heart on starting this, I'd like to give 
it a 
shot... :)

Currently I'm thinking the best way to deal with zoom markup-wise is like this:

1. Create a root child SVG element that would contain all other elements, but 
not 
including the selectorParentGroup.
2. Changing the zoom level will only change the viewBox attribute on this 
element, 
not the parent one. 
3. The selectorParentGroup will be a sibling to the zoom SVG element, thus 
allowing 
it to be unaffected by the zoom level. 
4. When saving, the zoom SVG element should be removed, with all children going 
back 
into the parent SVG. 

Quick illustration of the proposed DOM tree while editing:

<svg>
 <svg id="zoomBox" viewBox="0 0 320 240">
  <rect/>
  <ellipse/>
 </svg>
 <g id="selectorParentGroup">
 </g>
</svg>

Which exports to:

<svg>
 <rect/>
 <ellipse/>
</svg>

How does this sound?

Original comment by adeve...@gmail.com on 8 Sep 2009 at 1:20

• Changed state: Started

[GoogleCodeExporter]

This sounds good - I hadn't thought about the problem of the selector group 
getting
zoomed - clever.

One thing I'm worried about is that you will need to do a lot of calculations 
to get
the selectors and other 'editor cruft' sized right, but maybe this won't be too 
bad.
 (And bear in mind I have no other good ideas, so yours seems like the right approach)

Original comment by codedr...@gmail.com on 8 Sep 2009 at 2:21

[GoogleCodeExporter]

I have a file which was done in r611, which still validates when I open it with 
r611,
but doesn't when I try to open it with r612.

I'll attach it here (trying to find the error, so I'm copying each element one 
by one
in the source editor)

Original comment by worms_...@yahoo.com on 9 Sep 2009 at 4:03

Attachments:

• shark_svg-edit.svg

[GoogleCodeExporter]

Sorry wormsxulla - it looks like any editing of source is a problem at the 
moment.  I
thought you had tested that first and that this was a specific problem for this 
file.

Original comment by codedr...@gmail.com on 9 Sep 2009 at 4:28

[GoogleCodeExporter]

Ok r617 has some fixes for serialization of SVG back into the DOM.  Noted 
problems
left with Zoom:

- poly editing handles do not properly size
- changing the canvas size no longer works as expected
- selector positions/sizes are integerized (we will need to stop doing this so 
that
we can allow fine-grained editing)

Feel free to add others to this bug so we can shake them all out.

Original comment by codedr...@gmail.com on 9 Sep 2009 at 6:22

[GoogleCodeExporter]

Another problem is that the align tools aren't working as expected. All the 
selected
objects jump to the top left of the canvas and disappear :-)

Original comment by worms_...@yahoo.com on 9 Sep 2009 at 10:00

[GoogleCodeExporter]

Fixed canvas size changing in r627.

Also still to do:
- Rotation selection box needs fixing
- Zoom interface 
- Mousewheel zoom
- Draw custom zoom area

Original comment by adeve...@gmail.com on 11 Sep 2009 at 4:01

[GoogleCodeExporter]

I looked at the code for a couple minute this morning and did this:

Index: editor/svgcanvas.js
===================================================================
--- editor/svgcanvas.js (revision 627)
+++ editor/svgcanvas.js (working copy)
@@ -1863,7 +1863,7 @@
                        var box = selectedBBoxes[0];
                        var cx = parseInt(box.x + box.width/2), 
                            cy = parseInt(box.y + box.height/2);
-                       var dx = x - cx, dy = y - cy;
+                       var dx = mouse_x - cx, dy = mouse_y - cy;
                        var r = Math.sqrt( dx*dx + dy*dy );
                        var theta = Math.atan2(dy,dx) - angle;                      
                        x = cx + r * Math.cos(theta);
@@ -1882,7 +1882,7 @@
                        cury = current_poly_pts[1];
                    arr[0] = ["M", curx, ",", cury].join('');
                    for (var j = 1; j < len; ++j) {
-                       var px = current_poly_pts[j*2], py = current_poly_pts[j*2+1];
+                       var px = current_poly_pts[j*2]/current_zoom, py =
current_poly_pts[j*2+1]/current_zoom;
                        arr[j] = ["l", parseInt(px-curx), ",", parseInt(py-cury)].join('');
                        curx = px;
                        cury = py;

which seemed to fix poly-editing when zoomed a little (though not perfectly it 
seems).

Original comment by codedr...@gmail.com on 11 Sep 2009 at 4:35

[GoogleCodeExporter]

Cool, thanks! I've added it to r628 together with a fix for the rotation 
selection box.

Original comment by adeve...@gmail.com on 11 Sep 2009 at 4:50

[GoogleCodeExporter]

Cool.  Steadily it's looking better :)

One thing I think might help:  as soon as zoom level changes, either 
clearSelection()
or re-generate the poly grips...

Original comment by codedr...@gmail.com on 11 Sep 2009 at 4:55

[GoogleCodeExporter]

Ok, with my last checkin I think we're getting pretty close to saying the base
feature is complete.  The last thing left I think would be to change the 
rounding to
be consistent throughout the UI (not a minor feat).

It might be a straightforward task:  Could we do something crazy like replace
parseInt() with something that automatically would scale to the zoom factor?  
For
instance:

window.actualParseInt = window.parseInt;
window.parseInt = function(num) {
    var zoom = canvas.getCurrentZoom();
    return actualParseInt(num * zoom) / zoom;
};

Or maybe that'd be too crazy, but you get the idea.  Probably we want to 
introduce
this rounding in a controlled way instead of overriding a base JS function like 
this.

The above function is nice because it can be swapped out for parseInt() and 
returns a
number that has just the right amount of precision for the current zoom level.

Original comment by codedr...@gmail.com on 12 Sep 2009 at 2:52

[GoogleCodeExporter]

Looks like Issue 195 will cover this now - it may be that you can close this 
issue now...

Original comment by codedr...@gmail.com on 13 Sep 2009 at 1:12

[GoogleCodeExporter]

Think I'll leave this open until we have a basic interface...

Trying to decide which zoom options to start with, which (one or more) do people
think are most important? I'd really love to have them all, but not sure if that
would be interface overkill at this point.

1. Button to "Drag-zoom box" or click on drawing to zoom (can't zoom out)
2. Zoom out button, click on drawing to zoom out
3. Drop-down list of pre-defined zoom %s
4. Spinner with current zoom % (essentially includes zoom in/out buttons)
5. Options for: (could be fly-out buttons or entries in drop-down list)
    a. Fit to selection
    b. Fit to content
    c. Fit to page
    d. Fit to page width
6. Zoom slider

Google Docs includes: 3
Inkscape includes: 1, 2, 4 and 5
Illustrator includes: 1, 4 and 6

Personally I feel we need at least 1 and 4.

Original comment by adeve...@gmail.com on 15 Sep 2009 at 1:30

• Added labels: Component-UI, Usability

[GoogleCodeExporter]

I like 1 + 3 + zoomin/zoomout buttons the most.

Original comment by rusn...@gmail.com on 15 Sep 2009 at 1:38

[GoogleCodeExporter]

I like 1 + 4 but if you want to go with 1 + 3 for a starter interface that 
would be
fine with me.

Original comment by codedr...@gmail.com on 15 Sep 2009 at 2:43

[GoogleCodeExporter]

Thanks guys. I have added 3, 4 and 5 in r650, though 5 is not yet fuctional. 1 
still
to be added.

Original comment by adeve...@gmail.com on 15 Sep 2009 at 7:15

[GoogleCodeExporter]

I now declare this functionality complete!

Added: #1 and made first 3 options of #5 work. The one thing missing is an 
actual box
being drawn, but that can be added later. Also, the math still needs fixing on 
"Fit
to selection" zoom when multiple elements are selected, but it should work fine 
for a
single element.

Added bonus: Double-click on zoom icon to go back to 100% (standard feature on 
other
editors)

Original comment by adeve...@gmail.com on 16 Sep 2009 at 3:54

• Changed state: Fixed

[GoogleCodeExporter]

woot!

Original comment by codedr...@gmail.com on 16 Sep 2009 at 4:11