I am having issues with inconsistent SVG rendering of what seems to be a basic file between browsers. I need to find a way to make this SVG cross-browser, but can't seem to pinpoint the problem. Firefox 23 and Inkscape issues go away if the stop-color statements for the gradients are moved from the CSS to style = style="stop-color:#XXXXXX". Sadly, this is not an option because of the way this file will be used. This file validates on the W3C validator, and seems to only use simple features, but rendering is inconsistent. What is wrong?
I am not allowed to post images yet, so here is a link to an image showing the problem:
http://www.flickr.com/photos/95652985#N07/9754841655/lightbox/
SVG Source is here:
https://dl.dropboxusercontent.com/u/11366066/fire.svg
Thanks for help with this baffling problem!
I think your coordinates x1,y1, etc (for instance
<linearGradient id="id1" gradientUnits="userSpaceOnUse" xlink:href="#id0"
x1="32093.5" y1="4749.35" x2="37189.8" y2="4749.35">
)
could exceed the user space bounding box, thus got wrapped in Chrome, and clipped in Firefox, etc (also my Ubuntu SVG viewer get the same results as Firefox).
A bit of philosophy: SVG, like HTML, is required to be tolerant in rendering, then is common to have different behaviours where the 'simpler' specification is extendend (actually SVG is far from simple)
Edit: my SVG viewer reports as dimensions: 4252 x 2835 pixels 74,2 kB 34 %. Even if we multiply 4252 * 3 we are far below the x1,x2 values....
Related
I prepared two stackblitz examples for html2canvas. In the first svg element is a little smaller and it works in Firefox:
https://stackblitz.com/edit/angular-ivy-4vzrey?file=src%2Fapp%2Fapp.component.ts,src%2Fapp%2Fapp.component.html
In the second svg is a little larger and html2convas generates an error:
Error loading svg data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20_ngcontent-mid-c43%3D%22%22%20id%3D%22svg-container%22%20xmlns%3Axhtml%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22%20viewBox%3D%220%200%20347.2833251953125%20670.216674804
Here is the second stackblitz eg (the only difference is the second svg has a little more g elements):
https://stackblitz.com/edit/angular-ivy-ebc3jn?file=src%2Fapp%2Fapp.component.ts,src%2Fapp%2Fapp.component.html
Any ideas how to overcome this?
See here:
SVG filter: 97,02%
SVGs' feBlend, feImage, feGaussianBlur, feSpecularLighting, feMerge: around 50% support, like several other SVG's filters elements
how it is possible? what is the real browsers' rate support ?
thanks for any hint
I am using SVGPanZoom to manage the zooming of an SVG image in my hybrid Android (for all intents and purposes the same behavior as in Chrome) app. While zooming works well I have found a strange issue. My original inline SVG element goes like this
<svg id='puzzle' viewBox='0 0 1600 770' preserveAspectRatio='none'
width='100vw' height='85.5vh' fill-rule='evenodd' clip-rule='evenodd'
stroke-linejoin='round' stroke-miterlimit='1.414'
xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://
www.w3.org/1999/xlink'>
Initially this SVG element is empty and gets populated programmatically from JavaScript at run time after which I initiate SVGPanZoom as follows
var panZoom = svgPanZoom('#puzzle',
{panEnabled:false,controlIconsEnabled:false,
zoomEnabled:true,dblClickZoomEnabled:true,onZoom:postZoom});
panZoom.refreshRate = 10;
panZoom.zoomScaleSensitivity = 0.02;
The problem I have run into is this - I want my SVG image to fill the available area, 100vw x 85.5vhcompletely to do which I instruct it via the preserveAspectRatio="none"attribute above along with the viewBox="0 0 1600 770" attribute. I have found that this works - so long as I don't use SVGPanZoom. As soon as I initiate panZoom thezoomBox`attribute gets stripped out and I end up with an image that does not quite behave in terms of its default stretching/filling behavior.
SVGPanZoom is widely used so I assume that this behavior is down to me not quite setting it up properly. Dipping into the code I have found SVGPanZoom creates a cacheViewBoxand then proceeds to remove the original zoomBox attribute.
Which is fine if after that zooming works and the original behavior of the application does not change which is not what I find. What am I doing wrong here?
I've also run into this issue recently. From my research, this is just how the library works. I chose to live with this limitation for now but I found a couple other libraries that may work the way you intend (I haven't tried them yet):
jquery.panzoom is a jquery library that provides this functionality and also has some nice features. I know many people try to avoid jquery but it's pretty small and may do what you want. It handles SVG but I don't know what it does with the viewBox attribute.
react-svg-pan-zoom is a react component which may be useful if you are working in react.
I've also tried the PanZoom library but this also suffers the same viewBox limitation.
A note for anyone running into this thread. In the end I abandoned SVGPanZoom and decided to eschew the route of using any pan/zoom library at all. At the same time I decided to completely stop using the SVG viewBox and handle all zooming/panning entirely on my own through SVG transforms. The core steps involved
Wrap the entire SVG contents in a group to make it easier to manage the transform. I use the id attribute gOuter for this group
Set an initial scale for the SVG to occupy the desired client rectangle. In my case I had an original viewBox of 0 0 1600 770 intended to occupy 100% of screen width and 85% of screen height. So my scaling was scaleX = 1600/window.innerWidth and scaleY = 770/)0.85*window.innerHeight).
Apply this initial transform to the wrapping outer group, gOuter.setAttribute('transform','0 0 scaleX,scaleY)
Now in order to zoom to a an object whose virtual top left hand coordinates in the original viewBox were Ox,Oy you would use the transform
gOuter.setAttribute('transform',
scale(scaleX,scaleY) translate(-Ox,-Oy) scale(2*scaleX,2*scaleY) translate(Ox,Oy))
to zoom in by a factor of x 2. The important things to understand here
In SVG transformations are applied right to left.
Here we are translating the zoom point to the top l.h.s. scaling and then translating it back to its original location.
The problem is that we also need to allow for the original level of zoom through the initial scaling so we tag that on as one last transform
This leaves you in complete control of the zooming process and as a fringe benefit the operation becomes considerably more smooth than when using a pan/zoom library.
Similarly to this forum thread, I'm getting a NullPointerException when exporting a graph to SVG. It doesn't happen with all graphs, but once it happens for a particular graph, no amount of closing and re-opening the .gephi file will let me export.
Unlike the forum thread, getting rid of spaces in node labels doesn't help me. In the log file, there's a very suspicious line:
***** CSSEngine: exception property.syntax.error:org.w3c.dom.DOMException: The "stroke-width" property does not support dimension values.
AttrValue:3.7186165E-4
Exception:org.w3c.dom.DOMException
Since SVG is all about web pages, this looks like a plausible issue. This forum post seems relevant. Here's a quote from it:
Batik is correct in rejecting the content, although it is a bit
confused in the error message. 'stroke-width' is a CSS property and
as such can not use scientific notation, as you quoted (silly yes, but
that is what CSS2 has said for a long time). The error comes because
Batik is trying to interpret 'e-03' as a unit (like 'em' for example).
Any thoughts on how I can export my beautiful Gephi image to SVG?
The number values in SVG properties (as with CSS properties) do not support scientific notation.
The error message indicates that somewehere in your file you have that stroke-width value (3.7186165E-4).
This is obviously a bug in the gephi SVG exporter. You should report it to them.
In the meantime you could fix it with a text editor. In the above example you would need to find the element with:
stroke-width="3.7186165E-4"
and change it so that it doesn't use scientific notation:
stroke-width="0.00037186165"
Note that if there is one, there may be others. Hopefully not too many! Note that other occurrences may not necessarily be on a stroke-width attribute.
Tilemill works great, mostly very usable! I managed to get to the part where I am making svg exports of my map made with osm-bright as a starter. That seems to be fine but I cant work out how the resolution I specify for the SVG relates to the zoom levels. I guess it has something to do with the tile size, can someone help me understand this?
Thanks a lot, Joris.
First, for printing, the resolution is 90.7 ppi (some OGC standard or whatever). Some round it down to 90 ppi.
Zoom-to-scale relation is calculated in this table: 1:2132 on z18, 1:4265 on z17 and so on. Also see this page on OSM wiki for formulas.