Comment 3 for bug 481605

Revision history for this message
Feneric (feneric-gmail) wrote :

I'd think that probably the best approach would be to make one pass through and gather up / categorize regions by backgrounds if and only if they have no stroke or a stroke that matches their backgrounds. I've personally never seen a case in the wild where this sort of problem involved transparency or background patterns, so at first pass it may make sense to simply not include these at all (the simpler case of plain opaque backgrounds would give a better feel for how well it'd work). Once these regions have been categorized, any category with more than one could have an overlap search algorithm run on it (and I confess here that I'm currently naive regarding this type of algorithm; in cases where I've needed it it's always been already available, but I'm guessing that no matter what its form it'll quickly get slow as the number of objects increases, so running it category per category will probably be a lot more efficient than running it over the whole). For most of the SVG images I've encountered so far, there typically won't be that many regions in any given category, and the images that are exceptions are exactly the sorts that'd benefit from this.

I agree with you that it'd be best to correct the graphic designer. :) Unfortunately, I'm not viewing this so much from the perspective of my own use as I am from the perspective of widespread use of SVG for the Web (a la the svg2gfx.xslt filter I've been developing as part of the Dojo Toolkit), and I suspect that if just within a one-mile radius of where I sit now there's at least one such graphic designer, there are probably lots more of them scattered throughout the world, so having an automated way of cleaning up their messes is probably nearly as important as cleaning up the typical messes left by Illustrator.

I probably exaggerated when I said "hundreds". Probably "dozens" is more realistic. It just feels like hundreds when one is testing against it and trying to debug odd behaviors.

Anyhow, I've attached a recent sample SVG file demonstrating exactly what I'm talking about. It's a real-world sample that I've acquired and have been using for testing purposes -- it's not something designed to be punishing to any sort of SVG processing app. It was used to promote a particular political view prior to the recent local elections in Massachusetts, and is fairly likely to be (sadly) somewhat typical of what we can expect from at least some designers. It gave me particular fits as even though I was able to process it (apparently) correctly with svg2gfx.xslt, the result had mysterious (still not understood) troubles on MSIE that I'm still trying to track down. Since I had to actually put this into use prior to the aforementioned election, I ended up subbing in a bitmap in lieu of the SVG vectors for the single case of MSIE... not really what I'd intended. Anyhow, note the horror of the pig's mouth in particular. What ought to be a simple Bezier curve is instead composed of lots of little polygons. Converting those polygons into just one polygon is a big win. Other examples of places where adjacent / overlapping regions ought to be combined abound within the pig. I have no idea why the graphic was drawn this way; I've really only met the artist briefly and that was before I started looking at the details of this piece.

If I can help in any way, please let me know. I'm currently working with a couple other open source projects (mostly Repoze and Dojo at the moment) and so I'm a little restricted for time, but I'm quite familiar with Python and do see Scour as a worthwhile project that's complimentary to what I'm already working on.