Open GoogleCodeExporter opened 9 years ago
It seems to be the same problem reported in issue 1067
Original comment by mantma...@gmail.com
on 7 Apr 2013 at 3:43
This should be raised to high priority.
Original comment by astei...@gmail.com
on 8 Apr 2013 at 8:01
Issue is similar to Issue 1067 and Issue 1077 and Issue 1081
Original comment by zeee.sz...@gmail.com
on 12 Apr 2013 at 8:41
Please review the attached SVG file.
I've tested this in the current Firefox 20.0 release and Firefox Nightly:
23.0a1 (2013-04-15)
Firefox 20.0 will show the ellipse incorrectly
Firefox 23.0a1 (2013-04-15) will show the ellipse correctly positioned
This may be a slightly contrived example because in svg-edit trunk, the
svgcontent node does not have a transform="" attribute as it's probably getting
removed during the running app -- yet, as Jeff and Robert have pointed out on
the list, at some point a setAttribute("transform","") or
setAttribute("transform",null) is probably getting done.
In the attached file, if you do *not* have the transform="", the snippet *does
render properly* in Firefox 20.0...
Do I need to simulate a programmatic setAttribute with a javascript snippet and
a button to perform a setAttribute("transform","") ?
Original comment by mark.nic...@gmail.com
on 15 Apr 2013 at 7:41
Attachments:
Thanks to some of the insights provided by Jeff and Robert, I modified
recalculate.js.
With this svn diff patch applied to trunk, i was able to successfully open and
view SVG correctly with no strange offsets happening to the svgcontent element.
see: https://bugzilla.mozilla.org/show_bug.cgi?id=861188
I admit that returning null on a <svg> element in recalculateDimensions is a
bit heavy-handed, but it seems to be working for the scenarios that I attempted
to test.
I've also attempted a Firefox version detection using navigator.userAgent so
that this code will only apply to Firefox 20
I have not tried this code against 2.5, but in theory it should work.
Original comment by mark.nic...@gmail.com
on 16 Apr 2013 at 5:27
Attachments:
Thank you Mark!!
We have applied a similar patch to our 2.6 version.
I confirm that it works! (tested on Firefox 20.0.1)
Original comment by mantma...@gmail.com
on 16 Apr 2013 at 1:38
Hi Mark,
thanks a lot, this is working for us!
Just to say that in the stable version I'm using (I don't know exactly if it's
2.5 or 2.6), the steps to apply the fix are slightly different.
You have to:
1) Modify the file "svgcanvas.js"
2) Looking for the row: "var recalculateDimensions = this.recalculateDimensions
= function(selected) {"
3) Apply your patch:
"
if (selected.nodeName == "svg" && navigator.userAgent.indexOf("Firefox/20") >= 0) {
return null;
}
"
between the two instructions:
a) "if (selected == null) return null;"
b) "var tlist = getTransformList(selected);"
Original comment by marco.vi...@gmail.com
on 16 Apr 2013 at 1:54
Thanks Mark for the patch. Here a review comment: Can you just check if it's
an <svg> element and return early, it doesn't seem like it's valid for any
browser, right?
Original comment by codedr...@gmail.com
on 16 Apr 2013 at 6:35
It isn't valid yet!, it's being added in the SVG 2 specification. Firefox has
started to implement some of those changes in a default disabled state. In this
case not quite disabled enough though.
Original comment by longs...@gmail.com
on 17 Apr 2013 at 8:51
When the patch is "confirmed", can you also apply on branch 2.6?
http://code.google.com/p/svg-edit/source/detail?r=2509
Thanks!
Original comment by marclaporte
on 9 May 2013 at 2:52
I'm not sure if the above mentioned patch has been applied to the 2.6 branch,
but using that version of svg-edit I'm having this offset problem
Firefox Nighlty 23.0a1 (2013-05-09)
I'm not sure if a feature or two was reverted in Nightly, but I'm getting the
same result as was experience in Firefox 20.0, even after applying Marco's
fix-it edits to 'svgcanvas.js'
Thanks,
Rev
Original comment by stylogic...@gmail.com
on 9 May 2013 at 5:45
Note:
Could this be an issue with the client operating system, as well? I'm on
Windows 7 Pro and I've notice that after the first time I load svg-edit from a
particular source, every subsequent time I load svg-edit, the last file I was
editing is shown in the display. Beside being a little annoying, it has the
effect of propagating this bug, beyond the first time it occurs, which is when
I first load an SVG file using the open dialog. If I want to get rid of it I
have to clear EVERYTHING from my Firefox history (and I mean everything),
before I can load svg-edit without a previous file opening in the display, and
therefore sans the offset bug. Is this a Windows-only effect?
Peace,
Rev
Original comment by stylogic...@gmail.com
on 9 May 2013 at 5:51
Update:
OK, now I've gone back to Firefox 20.0.0.1
After the FIRST time loading svg-edit from a specific source, at which point
the offset bug does not occur, EVERY subsequent loading of the application from
that same source will produce the bug (whether or not I've used the open
dialog)...
UNLESS I do the following:
1) Close the window or tab in which svg-edit has been loaded
2) Chooses 'History' > 'Clear Recent History' (Ctrl+Shift+Del) from Firefox menu
3) Select 'Everything' from the Time Range to Clear dropdown
4) Check 'Cookies' (only this seems necessary in Firefox 20.0.0.1)
5) Click the 'Clear Now' button
Then, the next time I load svg-edit from that source I will have a blank canvas
that I can draw to with no offset problems. At this point, I can use the New
dialog without issues, but if I reload the window/tab, even if I haven't drawn
anything yet, the reloaded instance of svg-edit will exhibit the offset bug.
Also if I access the <SVG> tag editor window, as soon as I click 'Apply' this
bug will occur.
Thanks,
Rev
Original comment by stylogic...@gmail.com
on 9 May 2013 at 6:58
I encountered this (or related) issue in Firefox 21 and verified that it also
shows up in IE 10.0.5 while using svg-edit 2.6.
I added the patch to svgCanvas.js and cleared the cache as well.
Differing from the example page on the svg-edit home page, my implementation
involves embedding the editing interface inside a div. When the interface is
first loaded no issue appears. After scrolling the parent page, drawn elements
appear below (y axis) where they should be the amount that I have scrolled,
x-axis is fine. Returning the scroll of the page to the top corrects the
problem.
If I zoom the edit interface, drawn elements now appear to the lower right the
amount I have zoomed. Returning the interface to the original zoom corrects the
issue.
Original comment by NotionSl...@gmail.com
on 28 May 2013 at 6:40
I am seeing this bug in firefox 23.0 again. here it moves horizontally only
outside the canvas
Original comment by imranash...@gmail.com
on 16 Aug 2013 at 12:14
I know this is a little late since version 2.6 has already been released, but
I've just started using svg-edit.
What's happening is the same as what's been reported by stylogic.
You can use it fine on firefox, but after i saved a svg file and opened it,
everything that's drawn, placed or moved is half the screen to the right and to
the bottom.
My O.S. is Ubuntu 13, the issue started when I was on firefox20, but now I've
upgraded it to firefox23 and the issue is still here.
My svg-edit version is 2.6 and I've applied the patch to svgcanvas.js, with no
success (actually it seems the problem isn't even related, since i tried to
state some alerts and it just didn't happen when i started drawing).
Hope my comment helps in the fixing of said issue, since it's a really annoying
one.
I will probably look into the issue myself for a while, but, just in case.
##BTW, I don't think it's related to the view-source problem
Thanks.
Original comment by osmar.ma...@gmail.com
on 5 Sep 2013 at 1:41
In svgedit.compiled.js find viewBox:"0 0 " and set viewBox:"640 480 " then it
work on firefox.
Original comment by vi...@cybertrontechnologies.com
on 25 Sep 2013 at 6:47
Hi,
hitting "CTRL + F5" multiple times, especially when the canvas is still empty,
seems to clear the cache & delete the old image...
Original comment by Lucian.D...@gmail.com
on 16 Dec 2013 at 10:45
Hi,
I confirm that the patch proposed by Mark that was working successfully on
Firefox 20 (see post #7) is currently not working anymore neither for FF 25 nor
FF 26, because the code execution is not going anymore into the function
"recalculateDimensions" during the creation of a new shape (e.g. a rectangle in
my case).
Any new suggestion?
Thanks,
Marco
Original comment by marco.vi...@gmail.com
on 18 Dec 2013 at 10:58
I also tried the solution suggested in post #17, both in the last version
available on the website and in the version I was using in April 2013 (that
does not have the svgedit.compiled.js file).
Unfortunately, even if the shape this is drawn in the right position, when you
select it the selection border (and the controls that enables rotation and
resizing) are still in the wrong position in the lower right area.
Now I'm stuck: this problem can be seen in the public Svg-Edit Demo
(http://svg-edit.googlecode.com/svn/branches/2.6/editor/svg-editor.html) only
with the latest release of Firefox, Chrome and IE are working fine.
Any patch/suggestion from the developers?
Thanks,
Marco
Original comment by marco.vi...@gmail.com
on 18 Dec 2013 at 11:15
[deleted comment]
[deleted comment]
I tried the solution suggested in post #17, in svg-edit2.6.
It have another problem, the zoom functionality is working at the right bottom
not at cursor point and the output file coming as empty in all the browsers.
Original comment by sunilkum...@gmail.com
on 5 Feb 2014 at 7:38
This has been fixed in the trunk version of svg-edit:
https://code.google.com/p/svg-edit/source/detail?r=2524. You can replace the
code in that revision in your svgcanvas.js file if you want to keep using 2.6.
View the trunk (latest) demo to see it working correctly:
http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html.
Original comment by breit...@gmail.com
on 24 Feb 2014 at 11:41
i had tried #24 this solution but but it's not worked for me, still i'm facing this problem, i'm using SVG 2.6 Version.. Anyone Fix This problem
Thanks in Advance
Original comment by ckantc...@gmail.com
on 26 Feb 2014 at 2:33
Hi, just look at the issue 1077
(http://code.google.com/p/svg-edit/issues/detail?id=1077), the fix suggested
has solved the problem for me!
Original comment by marco.vi...@gmail.com
on 13 Mar 2014 at 9:55
Original issue reported on code.google.com by
mantma...@gmail.com
on 7 Apr 2013 at 3:38