I am using Raphaël 2.1.0. I draw several paths, circles, and rectangles, and everything seems to work fine on both IE9 (SVG) and IE8 (VML). However, when I try to add text to the canvas using text function, IE8 always throws Unspecified error, and the error seems to be on this line, raphael.js, line 5179 character 13, which is
var brect = span.getBoundingClientRect();
I don't see any error on IE7 though. Does anyone has an idea what might be the issue?
Thanks!
Related
I am experiencing two weird things happening with svg rendered in safari (works fine in Chrome/Edge/FF and heck even IE)
Lines not defined in SVG will appear and disappear randomly when panning around.
Lines defined in SVG might disappear randomly when panning around.
Not really that easy to describe so I made a video for it
https://youtu.be/BqlItab0k_g
I did not use any fancy SVG feature like script or media query. The only elements used are text/path/rectangle.
The SVG is generated by me and optimized using SVGO
[Codepen](https://codepen.io/alt22247/pen/vwzBmL)
The svg is base64 encoded since I can't upload svg to code pen. Had to use code pen instead of SO built in since the base64 encoded img text exceed SO limit. Feel free to decode it back to text.
I can't think of any way to mess up the SVG without causing a parse error so I believe this is a Safari bug. But we need to support Safari regardless (typical life of a web dev).
So the question is: What is causing this and is there any work around I can do rather than wait for Apple to fix it 10 years later?
I am building an AureliaJS based application which contains a SVG based component. My problem is that in MS Edge, the gradients of this SVG are not rendered (see image below: the "gauge" is supposed to be transparent and the two circles green). It is correctly displayed in all the other browsers I tested (FireFox, IE11, Chrome).
The gradients are defined inside the SVG in a defs section. They are then used by their ids.
I tried:
To open the SVG part of the component as an SVG file in Edge. Strangely it renders correctly. So I guess the SVG is correct.
To remove the Aurelia markup: the problem is still here.
To change the value of fill (currently fill: url(#gauge-fill-2)) into fill: url('#gauge-fill-2') or fill: url('/#gauge-fill-2') without success.
I also get the message below in the console, which disappears if I remove this SVG (I translated it from French as I have a French edition of Windows 10)
XML5633: The name of the ending tag doesn't match the name of the starting tag.
Line. 60, column 7
However, when I read the code, I couldn't find any problem about closing tags. To be sure of this, I remove most of the code and left only one element with a gradient on it. This message was still there.
The full code of the component is available here: https://bitbucket.org/arenaoftitans/arena-of-titans/src/9f5f70ff3fc71832bcac90ce0dcc5204a471b095/app/game/play/widgets/gauge/gauge.html?at=master&fileviewer=file-view-default
Any idea of what the problem might be and how to solve it?
The problem is solved by the creators update. I just need for it to be widely deployed.
I created an SVG file, and in inkscape it looks like this:
But when I render it by a browser, the arrows get screwed up:
This (above) is the actual svg (link), and in case it renders correctly in your browser, here is how I see it (this time it's a screenshot in png):
It's the same in the latest Firefox and Chrome.
This file was created in inkscape 0.48 on Windows, and when I re-open it in inkscape, it renders correctly. Is there a way to make the browser rotate the arrows?
There are bug reports of this for Chrome, Firefox, Inkscape, and Wikimedia. It turns out that some renderers get the arrow direction wrong when just one handle, the one at the beginning of the curve, has zero length. Currently, Firefox, Inkscape, and LibreOffice Write get it right, while Chrome gets it wrong.
To create an example of such a line, draw a line in Inkscape, then add a curved midpoint. Inkscape then makes both segments Bezier curves, but the end segments have zero length handles. If you then delete the midpoint, Inkscape will try to match the curve, and will create non-zero length handles for the endpoints.
Reported as bug in Firefox in 2015, and fixed
Reported as bug in Chrome in 2015, and not fixed
Reported as bug in Inkscape in 2006, blamed on user and closed as "out of date" in 2009
Reported as bug in Wikimedia in 2015, by me
Discussion of ambiguity in SVG spec
A fix that I have noticed in Inkscape is to first select the "edit paths by nodes" option, and select each endpoint and select the option to "make the selected nodes smooth" from the path editing toolbar.
I found the solution:
The problem was that for these lines Bezier curves were used, and even though the lines were straight, it caused the problem. Once I replaced the curves with "diagram connectors", the problem disappeared.
You're using degenerate bezier curves which display as straight lines. Neither Chrome nor Firefox prior to version 38 cope with these when determining marker angles.
This has been fixed in Firefox 38 by bug 1129854. I think there's an equivalent Chrome bug too.
Just want to get a sanity check on this before wasting too much time - does Batik actually have usable JavaScript support in its SVG display and rasteriser?
Problem: I've got code which generates SVG files, using a few thousand lines of fairly complex JavaScript. This works on Firefox, Chrome, Opera, Safari, and IE9. I've spent the morning trying to get Batik to display a sample SVG file (in Squiggle) and to rasterise it to png/pdf/etc. I've already fixed one problem (I had to move a text node into the DOM to get splitText to work), and the next problem is only a few lines down (nodeValue.trim() doesn't work on a text node).
Just about to give up and ignore Batik (v1.7, downloaded yesterday), unless someone has some positive experience of it?
Has anybody ever had any issues with transitioning the opacity of an SVG text element? I'm using both the fill-opacity style and the stroke-opacity style to fade the text elements into and out of existence. It works fine on most browsers, but doesn't transition at all in Chrome on Mac -- the text just pops in and out all at once.
I tried setting the "opacity" attribute in addition to fill-opacity and stroke-opacity and that does seem to make it work, although now I see a weird flicker effect just before and after the transition runs. It's like it's setting it to opacity=1 for a split second before it sets it to 0 and then transitions to 1.
Another interesting thing is that other shapes (circle, rect) fade in and out just fine with nearly identical code to what I'm using with text.
This does seem to be weirdness with a specific browser, but I'm wondering about other people's experiences with opacity on text elements. Are there tricks to get it to behave consistently?
What version of Chrome are you using? I noticed a bug in Chrome dev some time ago when working on the word cloud but it appears to have been fixed as of 19.0.1077.3 dev. Perhaps the fix hasn't made it into your particular version yet?
In my case, using opacity fixed the problem temporarily. The flicker effect could be due to exponent notation not being parsed for very small numbers; you can try using 1e-6 instead of 0 to get around this.
For an animation I made some months ago I toggled the style and used webkit-transition, in combination with visibility: hidden. This seems to work well. If that doesn't work, you could try transitioning to an opacity near zero.