oksvg icon indicating copy to clipboard operation
oksvg copied to clipboard

Strange colors when trying to convert svg icons to png

Open probonopd opened this issue 6 years ago • 11 comments
trafficstars

I am getting strange colors when trying to convert svg icons to png.

The test files and code are attached.

files.zip

Am I missing something obvious?

probonopd avatar Oct 22 '19 19:10 probonopd

Does this happen with all svg files or just this one?

srwiley avatar Oct 23 '19 16:10 srwiley

Also with other svg icons on my Xubuntu system from /usr/share/icons/hicolor/scalable.

probonopd avatar Oct 23 '19 16:10 probonopd

I get the same result as you. There are quite a few unsupported elements in this particular svg, most of which are in the metadata section. You will see them if you turn error reporting on. In this case, after the meta data section is removed I get two elements that are not supported:

2019/11/11 19:32:17 Cannot process svg element namedview 2019/11/11 19:32:17 Cannot process svg element grid

Although I am not certain this is the problem, until oksvg supports those two things I think it will not draw correctly. If you can slim it down to a file without those elements and it still does not draw correctly, I will take another look.

srwiley avatar Nov 12 '19 03:11 srwiley

Attached are two versions of the icon: in tagsremoved.svg I have removed all offending tags until oksvg does not complain anymore. The conversion still has the wrong colors.

For slimmed.png I have sent the PNG through an optimizer; this one results in a crash.

https://github.com/srwiley/oksvg/files/3837681/icons.zip

probonopd avatar Nov 12 '19 18:11 probonopd

probonopd, sorry for taking so long to get back to you. The tagsremoved.svg file does not appear as a link on my end. Please provided a link like you did for files.zip. thanks, srwiley

srwiley avatar Jan 16 '20 02:01 srwiley

https://github.com/srwiley/oksvg/files/3837681/icons.zip

probonopd avatar Jan 16 '20 20:01 probonopd

I think I have this mostly fixed; see the "gradfix" branch oksvg and update rasterx.

The problem lies with gradients in a couple of ways. The magenta you are seeing is because that is the default color I used for a gradient with no stops as a debugging tool. The default is now black.

Also, there are some gradients with no colors specified in their stops. This is apparently OK as per the SVG2.0 specifications as you are supposed to then use the current fill or line color. So, now a gradient defined in the defs might change depending on the path in which it is used, which took a little more work to implement.

Finally, in your example file there are radial gradients that have an xlink:href to a linear gradient. xlink:href is deprecated, but even if you substitute in the preferred use(url) syntax, it makes no sense except perhaps to copy the list of stops into the radial gradient. However, the default SVG renderer in linux just ignores that type of linking and so does oksvg for now.

Since there are some substantive changes I am putting the fixes in the "gradfix" branch of oksvg for a couple of weeks. If I don't hear back from any interested parties, I will merge it into the main. Also reload rasterx before testing the fix, since the default color for no stop gradients is there.

srwiley avatar Jan 20 '20 21:01 srwiley

Thank you very much @srwiley. I no longer see the pink/magenta color, but now some icons are rendered in black/grey colors that should be colorful. I'd still consider it an improvement, but apparently the issue is not entirely solved yet.

I will post examples as I encounter them.

probonopd avatar Jan 22 '20 19:01 probonopd

I agree, there is still some stuff going on. What exactly did you do to generate the "tagsremoved" version of the hard drive icon? Because on my system that appears to render correctly, while the original does not.

srwiley avatar Jan 22 '20 20:01 srwiley

Just a text editor :-)

probonopd avatar Jan 22 '20 22:01 probonopd

Attached are some examples.

examples.zip

probonopd avatar Jan 22 '20 22:01 probonopd