Get SVG-edit working in IE9

[GoogleCodeExporter]

The SVG Web project is getting much more attention lately.  Though we have
focused on making it work in the 'big three' platforms, it would make sense
to look at how adaptable our codebase is to the SVG Web plugin so that IE
users can also use SVG-edit.

Fortunately it looks like much of the work has already been done for us
here:
http://groups.google.com/group/svg-edit/browse_thread/thread/79c8c4c76bef43f4

This issue will track the changes that need to occur on trunk to align with
antimatter15's work (I have yet to do a diff).

Original issue reported on code.google.com by codedr...@gmail.com on 25 Aug 2009 at 12:34

[GoogleCodeExporter]

I've updated it a bit, and I have a patch that adds svgweb stuff. It's better 
than the 
last one, and supports selecting shapes, multi-select, and less errors.

http://antimatter15.com/misc/svgweb-svgedit/svgweb.diff

Original comment by Antimatter15 on 25 Aug 2009 at 2:29

[GoogleCodeExporter]

I submitted the first patch in r467 but I had to do one modifcation to the 
getBBox()
method since the merge failed.

Please work from the svn up copy.

I also couldn't get the force-flash URL variable to work via Google Code (but it
worked from my local copy).

Original comment by codedr...@gmail.com on 25 Aug 2009 at 3:12

[GoogleCodeExporter]

Since we have Google Chrome Frame and IE9 will support SVG, I'm thinking this 
is now a low priority item.

Original comment by codedr...@gmail.com on 21 Jul 2010 at 4:47

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by adeve...@gmail.com on 27 Jul 2010 at 11:23

• Removed labels: NeededFor-Future

[GoogleCodeExporter]

Repurposing this bug to target implementation in IE9.  I haven't looked at the 
latest preview, but the word on the street is that it's got a lot of goodness 
in it.

Original comment by codedr...@gmail.com on 19 Aug 2010 at 8:48

• Changed title: Get SVG-edit with IE9
• Added labels: NeededFor-2.6, Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

Original comment by codedr...@gmail.com on 19 Aug 2010 at 8:49

• Changed title: Get SVG-edit working in IE9

[GoogleCodeExporter]

Okay, started specific IE9 support in r1679. Icons don't load yet (not even the 
fallback ones), but you create and select some elements. Lots of other bugs 
left too.

Discovered the following annoyances:
1) No support for DOMParser() (though there is an equivalent)
2) No importNode support (should probably write a workaround for that)
3) Mouse coordinates appeared wrong, had to write a hack to fix that...not sure 
yet if that's due to the point transformation in this code:
        root_sctm = svgcontent.getScreenCTM().inverse();
        var pt = transformPoint( evt.pageX, evt.pageY, root_sctm );
Or if evt.pageX/pageY is wrong.
4) Can't set bbox values to a real bbox object using bbox.x = n; Not a big 
deal, will just have to do some rewriting for that.

So this isn't going to be much fun, but I'm sure we can get 75%+ of our 
functionality to work in the end. :)

Original comment by adeve...@gmail.com on 23 Aug 2010 at 8:24

[GoogleCodeExporter]

Original comment by adeve...@gmail.com on 23 Aug 2010 at 8:25

• Changed state: Started

[GoogleCodeExporter]

Great start!  I can't test it yet though (have to wait until tonight).

I don't have a lot of time, but I can volunteer to help report some bugs and I 
can write a blog post.  Let's get these issues drawn up the flagpole asap so 
they can fix it before release :)

importNode - that's surprising (and unfortunate).

mouse coordinates - I noted that this test failed in IE9p4, I think on the 
getScreenCTM() line.  Perhaps related? 
http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-types-basicD
OM-01-b.html

Original comment by codedr...@gmail.com on 23 Aug 2010 at 8:34

[GoogleCodeExporter]

Where ever I go, I see Jeff helping us. Thanks Jeff!!

This is all very exciting to see the community rallying around SVG as a 
standard.  
I debugged through this as well.  Here are the issues I found.
In general, we all must stop checking for IE. For example, in the SVG Edit Code

text2xml:function(bi){var bh;try{var bk=($.browser.msie)?new 
ActiveXObject("Microsoft.XMLDOM"):new DOMParser()

the above code creates an ActiveX object of XMLDOM which doesn't work with the 
follow on XML items.  If the if browser.msie is removed, and the correct check 
for the presence of DOMParser were used, an IE9 DOM parser would be created 
consitent with standards.

This would also make importNode work

I recommend (and I will help soon, after SVG Open) to look for these IFIE stuff 
and help me eradicate it!! :)

Patrick Dengler

Original comment by alexissp...@gmail.com on 23 Aug 2010 at 10:02

[GoogleCodeExporter]

Awesome Patrick, thanks for the tip.  Care to make a SVN patch? :)

Yes, it will take all of us a long time to unlearn habits like checking for IE 
- but glad to unlearn it! :)

Original comment by jeffschi...@google.com on 23 Aug 2010 at 10:23

[GoogleCodeExporter]

Yeah, I'm normally not one for browser sniffing, in this case I just wanted to 
see what it would take to get basic editing to work. Don't plan on having any 
IFIEs left by the time 2.6 is released. :)

Oh, except for dealing with this bug: http://is.gd/enaOk Not sure if there's a 
way around browser sniffing that. :(

Original comment by adeve...@gmail.com on 24 Aug 2010 at 2:26

[GoogleCodeExporter]

A looked at this referenced bug, and I expect that it is probably a security 
issue.  If you can help me, perhaps I can help with this.  Since I am not 
familiar with the details of all standards, bear with me.

Is this method for supporting URI's in the URL a standard?

Also, could you point me to the code in SVG Edit where this is used? I cannot 
find it.

Patrick Dengler

Original comment by alexissp...@gmail.com on 24 Aug 2010 at 3:05

[GoogleCodeExporter]

Hi Patrick,

I am not  a security expert either.

Summary information about data: URIs can be found here: 
http://en.wikipedia.org/wiki/Data_URI_scheme along with reasons why IE8 limits 
it to 'non-navigable' content.’  To my knowledge all other browsers do 
support browsing to data: URIs in the address/location bar.  Since that largely 
seems to be a UI issue, I would not expect it to be standardized behavior.

Hope that helps.

Original comment by codedr...@gmail.com on 24 Aug 2010 at 3:43

[GoogleCodeExporter]

Sadly information on how and where to support data URLs is indeed currently 
missing. Peter Beverloo recently brought this issue up in detail on the WHATWG 
mailing list here:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028011.html

So admittedly it is not (yet) a standard, currently I can only appeal to the IE 
team's desire to have cross-browser support for features, since as mentioned 
this works in all other browsers.

In svg-editor.js this is used inside the saveHandler function, specifically in 
this line:
var win = window.open("data:image/svg+xml;base64," + Utils.encode64(svg))

Additionally, the exportHandler (for PNG conversion) uses the canvas 
toDataURL() method to generate a PNG data URL, which is also loaded in another 
window in this line:
exportWindow.location.href = datauri; 

(the actual window is opened earlier to prevent a popup warning)

Thanks, let me know if I can help out in any other way.

Original comment by adeve...@gmail.com on 24 Aug 2010 at 4:36

[GoogleCodeExporter]

Since this is not a standard, I will talk to our HTML working group folks. In 
the mean time, is there a workaround for this behavior in the SVG Edit control 
(again forgive me that I am not looking more closely at this code but I am 
switching between looking at libraries/code and getting my SVG open 
presentation ready )

Original comment by alexissp...@gmail.com on 24 Aug 2010 at 8:11

[GoogleCodeExporter]

Yes, actually, in r1679 I made the save option open up the source editor, with 
a note that users can copy & paste the text and save it as an .svg file. I 
think that's the best we can do for now.

Original comment by adeve...@gmail.com on 24 Aug 2010 at 8:21

[GoogleCodeExporter]

SVG-edit relies on this behavior to do a pure-clientside way of letting the 
user save his/her SVG file to their hard drive.  They click "Save" and they get 
a page that just has the SVG file on it (via opening a window to the data: URL) 
and then they click File > Save in the browser.

This is the best we can do until all browsers support the W3C FileReader and 
FileWriter APIs.

We could open a page that has a <img> on it that has the data: URL.  From 
reading that Wikipedia article, I suspect this might work in IE9, but it 
wouldn't let the person save the file via File > Save Page.  We could put text 
on the page that says "Right-click on the image below and save it to your hard 
drive".  That's even worse for the user, but perhaps it's a suitable 
alternative for IE9 in the short term.

Original comment by codedr...@gmail.com on 24 Aug 2010 at 8:23

[GoogleCodeExporter]

By the way, I'm getting closer to getting the icons to work...may be able to 
get there tomorrow.

Original comment by adeve...@gmail.com on 24 Aug 2010 at 8:39

[GoogleCodeExporter]

As promised, the icons now appear in r1680. Unfortunately it required quite a 
bit of workaround code in jquery.svgicons.js, hopefully there's a way to reduce 
that.

Also you'll note some icons look a bit odd, that's because any element with a 
transform attribute fails to transform properly (mostly causing unrotated 
elements). I've traced this bug down to the attribute value giving an incorrect 
result when queried though for example getAttribute('transform'). 

For example, an element with transform="rotate(45, 105.5, 191.5))" gives 
"rotate(45 -1.#IND -1.#IND)" when queried. Will file a bug on this on Microsoft 
Connect, unless you already know about it...

Original comment by adeve...@gmail.com on 25 Aug 2010 at 3:22

[GoogleCodeExporter]

r1681 has a better formula for coordinate calculation, so drawing things like 
<rects> works as expected now. Still using a sniffer there until I can be 
bothered to write something that checks if a valid root_sctm is given.

Original comment by adeve...@gmail.com on 25 Aug 2010 at 7:21

[GoogleCodeExporter]

Patrick - In comment #10 you say:
 "If the if browser.msie is removed, and the correct check for the presence of DOMParser were used, an IE9 DOM parser would be created consitent with standards.

This would also make importNode work"

However, IE9pp4 does not appear to support the DOMParser() object and for a 
similar bug I have been unable to import (standards-compliant) XML nodes using 
importNode(). I have filed a bug on this here: http://is.gd/eEZ42

Currently the only way around this that I can see is to traverse through each 
DOM object and re-create SVG elements with the data, which is of course far 
from ideal. If you know of a better method, please let me know. Thanks!

Original comment by adeve...@gmail.com on 26 Aug 2010 at 2:53

[GoogleCodeExporter]

Since I've got significant functionality working in the IE9 Beta by r1723, I'm 
closing this issue. :) 

Remaining bugs can be opened separately.

Original comment by adeve...@gmail.com on 16 Sep 2010 at 5:12

• Changed state: Fixed

[GoogleCodeExporter]

Awesome work! Hard to believe this day has finally come - IE supporting SVG

Original comment by adrianbj...@gmail.com on 16 Sep 2010 at 6:15