lib gives wrong output
Closed this issue · 15 comments
Hi Ivan!
I've attached zip containing an original svg and result of dom->toString() saved to svg again and rendered by google chrome.
There are some ugly black lines on the car's hood and doors .
Could you please investigate this problem and give us small fix for this nice car?
Thanks a lot.
car.zip
Fixed in svgdom version 0.3.2:
https://travis-ci.org/igagis/svgdom/builds/274193599
https://ci.appveyor.com/project/igagis/svgdom/build/master-410
But I think another fix in svgren will also be needed.
Also fixed it in svgren version 0.4.39:
https://travis-ci.org/igagis/svgren/builds/274280273
https://ci.appveyor.com/project/igagis/svgren/build/master-413
Hi again!
Thanks for the quick fix.
It helped for our nice sport car.
But there are some similar problems with back.svg image.
It will be very nice if svgdom can produce the same image as original is.
Again, many thanks for the nice lib and excellent support!
it will take some time to nail down the causes of all those problems, since this back.svg is quite huge, it is difficult to find the affected objects in it...
@Papirosnik do you happen to have smaller SVG's which reproduce some of those problems?
@igagis
Nope )
All my smaller svgs give pixel perfect output.
What's about small automation?
You might load one dom from the original svg and second dom from the 'recycled' svg.
And then just iterate elements in both doms and compare them each to other.
Or just compare amount of attributes in each element...
@Papirosnik this won't work unfortunately. Those problems you discovered are due to something is not supported by svgdom, so comparing DOMs loaded by svgdom will give identical DOMs.
What is needed is to build minimal SVG which reproduces the problem. So, the strategy is to strip out all the stuff from the SVG file which has nothing to do with the affected elements. But since the original SVG file is that huge it is hard to do that, even simple text editor complains about its size when I try to view that SVG file :), no idea which software you used to create that, I tried to open it in Inkscape and it takes minutes to just change the zoom level, I'm not saying about any editing :D.
So, I will try to use text editor to narrow down the affected places into smaller SVGs, will take time, but I have no other way...
Ok, at the my rare non-busy minutes I also will be trying to locate those problematic elements.
either at least thinking how to find them )
Using BeyondComparer 4 and XMLsorted extension for it
I managed to find suspicious differences:
Original:
<filter color-interpolation-filters="sRGB" height="140%" id="Filter_10" width="140%" x="-20%" y="-20%">
Recycled:
<filter height="140%" id="Filter_10" style="color-interpolation-filters:sRGB" width="140%" x="-20%" y="-20%"/>
As you can see, 'color-interpolation-filters' attribute became 'style' attribute.
Is that ok?
Yes, this is OK, SVG allows specifying style attributes both ways. Those are equivalent.
Meanwhile I found several unimplemented filters: feColorMatrix, feBlend, feComposite. I'm going to implement those.
feColorMatrix, feBlend, feComposite elements are now supported in svgdom version 0.3.3.
https://ci.appveyor.com/project/igagis/svgdom/build/master-417
https://travis-ci.org/igagis/svgdom/builds/275040941
Excellent work!
I have circled the only difference I can see now.
Thanks a lot!
This time, I think it is a bug in Google Chrome, because Firefox and InternetExplorer render this back.svg without that white stuff behind the bushes. Only Chrome renders this white stuff.
Oh, that's good news!
I also have been noticing that that image looked a bit better without those white spots )
ps. these fe* elements are strongly expected in svgren)
Could you submit a bug about that to svgren please, and close this one then?