I try to convert an svg to png with ImageMagick ImageMagick-6.8.9-Q8 under Windows 7 (64-bit)
I tried this code:
C:\>convert -monitor -define registry:temporary-path=D:\ sourceSVG.svg targetPNG.png
I use -define registry... because I dont have enough space in C:. There are no errors printed in the prompt but the output PNG is all white. There is not a single pixel in any other colour. The SVG seems to be correct, I could open it with IrfanView.
This is how the SVG looks (it has over 3500 polygons):
<svg height="40900" width="49500">
<polygon points="15968.0,3603.0 15924.0,4238.0 16061.0,4234.0 16140.0,4203.0 16177.0,3661.0 15968.0,3603.0" style="fill:#FFFFA5;" />
<polygon points="23738.0,5019.0 23738.0,5020.0 23739.0,5020.0 23739.0,5019.0 23738.0,5019.0" style="fill:#FFBD00;" />
</svg>
What could be the problem? Propably too much polygons right? But there wasn't any errors.. How can I fix this problem?
Edit: In order to find out where the problem lies a tried a couple of things:
I checked whether the problem is caused because of too many polygons. So I deleted all polygons but two. Still same problem
I checked whether the problem is cause because of the ".0" so I removed them to have Integers. Still same problem
I checked wether the problem is caused by a too big width/length. So I halved the width/length and made sure to delete all polygons wich lied beyond the new width/length ( ~24000 each). Still same problem. I halved them again (~12000 each) and one polygon was shown and the other one was missing (there were 2 polygons in the svg)
Related
In Firefox 104 on Windows 10, the following SVG file shows as blank, empty:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 2769.2 1615.4">
<defs>
<style>
.fil1 {fill:url(#id0)}
</style>
<linearGradient id="id0" gradientUnits="userSpaceOnUse" x1="230.8" y1="2394.2" x2="2538.5" y2="2394.2">
<stop offset="0" style="stop-opacity:1; stop-color:#667DD1"/>
<stop offset="1" style="stop-opacity:1; stop-color:#8C9DDC"/>
</linearGradient>
</defs>
<g>
<polygon class="fil1" points="230.8,230.8 2538.5,230.8 2538.5,1384.6 230.8,1384.6 "/>
</g>
</svg>
Other browsers (e.g. Chrome) show the desired result: a rectangle with a gradient fill. The SVG appears to be empty in Firefox because Firefox does not show the fill.
Why does this work in other browsers, but not in Firefox?
In case it's of any interest: the example SVG presented here was exported from CorelDRAW 2021. I've removed extraneous markup from the original file.
A similar question already exists; why this new question?
This is a follow-on to the existing question "SVG Linear Gradient does not work in Firefox".
I originally—and, I acknowledge, incorrectly—posted this content as an "answer" to that existing question, because I could not post a code block as a comment to an answer for that existing question, and because I mistakenly believed that asking a new question was the wrong thing to do.
Here, in asking this question, I am following the advice of Robert Longson, the author of the answer to that original question, who offered me the following advice in a comment:
If it's not an answer to this question then you should delete it and ask a separate question. You can always include a link to this question in your new question so that it's not closed as a duplicate.
Done! Thanks for the advice, Robert!
Answering my own question...
In brief
User (my) error. I was inadvertently using UTF-16 character encoding instead of UTF-8.
The UTF-16 SVG file renders okay in Chrome, but not in Firefox.
In more complex SVG examples that include objects with single-color fills, everything except the gradient fills renders okay. The lack of gradient fills is a symptom of this character encoding issue.
In (embarrassing, to me) detail
Thanks to Robert Longson and ccprog for their comments on my question, which led me to this answer.
The snippet in my question works for me in situ, too, in Firefox 104 on Windows 10. I thought I'd tested it back in my now-deleted answer in the original question, but I've just opened that question in Firefox 104 on Windows 10 (where I can still see that now-deleted answer, although I understand others might not) and... it works there, too. I thought I'd tested it in that very context, but this tells me that I hadn't.
I'm very embarrassed about that, but I have to admit to it.
Mystified, I copied'n'pasted the working snippet from this question to a stand-alone .svg file. Again, that new .svg renders just fine in Firefox 104 on Windows 10.
So I compared that new .svg file with the .svg file that doesn't work. The comparison did not highlight any content differences, but did highlight that the two files had different character encodings. The comparison reported the file that does not work in Firefox (but works in Chrome) as "ISO-10646-UCS-2 BOM"; the new .svg file, which works in Firefox, as Window-1252.
Meanwhile, my text editor (I'm using jEdit) reports the character encoding of the two files as x-UTF-16LE-BOM and UTF-8, respectively.
My SVG files are typically UTF-8 (which, I understand, for printable characters with byte value 127 and below, matches Windows-1252; so I can understand
the comparison reporting that file as Windows-1252).
I currently have no idea how I changed the encoding of the problematic file from UTF-8 to UTF-16. I'll look into that. But, that's my problem.
Me and my team have problems with generating bitmaps out of polygons. We've tried a few different solutions in order to generate polygons sufficiently fast and have found generating SVG paths and then using CairoSVG to be the best solution for us. We are using the even-odd rule to fill the polygons. I apologies if I'm describing everything in an incorrect way in terms of vocabulary, I'm new to SVG. The pathes are created as:
path_entry = f'<path fill="rgb{rgb_color}" fill-rule="evenodd" d="{svg_path}"/>'
With header
<svg
xmlnsXlink="http://www.w3.org/2000/svg"
preserveAspectRatio="xMinYMin meet"
style="color:green;"
>
We only allow the bitmap to have a set of color values. The value of a pixel should be that of the polygon which it's inside. A problem we've encountered is that the edges of the polygons "splits" pixels, i.e a pixel can be both on the edge/inside of polygon A and polygon B. See the image below where the edge between the black, green and grey area gets a mixed color.
We've currently solved this by finding each pixel that doesn't have an allowed color. We then use numpy roll to fill the value of these pixels with the value of its neighbours according to a solution found on this site.
for shift in (-1,1):
for axis in (0,1):
a_shifted=np.roll(bitmap_only_correct_colors,shift=shift,axis=axis)
idx=~a_shifted.mask * bitmap_only_correct_colors.mask
bitmap_only_correct_colors[idx]=a_shifted[idx]
The problem with this solution is thin diagonal polygons, 1-2 pixels thick. All pixels of these polygons get the mixed value and are therefor removed. This causes the thin polygons to be partly removed creating dotted lines instead of full lines, see the image below.
My question is: Can we solve this problem with the edges of the polygons not getting fixed values in another way? The best solution would be to add some kind of setting to the SVG-Document before generating the images.
Thank you!
Turn off anti-aliasing i.e. set shape-rendering="crispEdges" See the SVG specification for more details about this CSS property.
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.
I have a number of <circle> elements each inside their own <g>. To move the circles around I'm applying a "translate" transform on each <g>.
What I notice is that as the circles are moving, some of them seem to get slightly truncated. As soon as they come to rest they look just fine so it is just while they are in motion. The truncation effect looks something like what you'd see if you had a square viewport the same size as the circle and then moved the circle slightly out of centre. It just flattens slightly on one side.
This is what one of my element groups looks like:
<g class="datapoint dot" transform="translate(360,56)">
<circle class="rendering" style="fill: #3182bd; stroke: #225b84; stroke-opacity: 1; fill-opacity: 1; " r="7"></circle>
</g>
When I run the transition watching the debugger I can see the values in "translate" change but everything else stays the same. So it doesn't seem to be something I'm doing wrong, but you can never be sure of that. :)
One final comment is that I do see this in multiple browsers (tried Chrome and Firefox so far).
Has anybody encountered this kind of thing before?
Probably a bit late for you but I've noticed similar things when using transform: scale(). The SVG shape is limited to the files original size. If the shape gets enlarged bigger than this then it will be cropped.
My fix was to make the bounds of the SVG bigger than the shape itself so that it has some room to expand into.
I'm using FabricJS and I encounter a problem with the display of my SVG in the canvas:
the result is displayed outside the selection box of fabricJS (due to a translation ?)
the anchors of the selection disappear after a transformation and then it's impossible to find them back.
Here is a screenshot :
I'm using an output SVG of Potrace and I think it's the origin of my issue.
Here is the code of the SVG: SVG code in pastebin
You can test it with FabricJS on this page: FabricJS Kitchensing example.
Just paste the code of the SVG in the "Load SVG" area, then resize and rotate the section box to display the SVG.
Do you know the part of my SVG code or the part of the fabricjS code that causes the issue ?
If so, can I change it easily by myself ? If not, is it possible for anybody to correct or locate the possible mistake?
Thank you very much for your help.
EDIT: seemingly, FabricJS doesn't like this line of the SVG:
<g transform="translate(0,648) scale(0.098780,-0.098780)" fill="#000000" stroke="none">
And more especially the translate and scale attributes… How to fix it?
EDIT2: the solution would be that the translate and the scale are respectively equal to (0,0) and (1,1) or, better, that they're applied to the coordinates.
Does anybody have an idea to do that with Potrace or JS script?
2 years after, fabricJs is now able to fully parse and manage this SVG.
Just paste the old pasteBin SVG code in the kitchenSink demo and you will see that it loads fine.
Lots of improvement happened recently in the SVG parsing area.
I know this is not an answer as stackoverflow user would expect, but better to know that to think this is may still be a problem.