Closed GoogleCodeExporter closed 9 years ago
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
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
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
Original comment by adeve...@gmail.com
on 27 Jul 2010 at 11:23
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
Original comment by codedr...@gmail.com
on 19 Aug 2010 at 8:49
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
Original comment by adeve...@gmail.com
on 23 Aug 2010 at 8:25
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
codedr...@gmail.com
on 25 Aug 2009 at 12:34