Just to be sure: what will be your end product? If in the end you're making a bitmap, don't worry, just export at a really, really high resolution (and scale down if needed) and you should be fine (the seams will still be there, but they'll more or less be averaged out).
If you're exporting to PDF you can stop trying to use filters right now, because it won't work (as far as I know, and especially some of the more esoteric options are bound to be problematic). Unless you let Inkscape render any filtered objects to a bitmap, but then you're essentially back to exporting a bitmap.
So all of the discussion about using filters to solve your problems only applies to the case where in the end you want to show the SVG. Also, you should test anything you do in the renderer that will ultimately be used, as different renderers can give different results (mostly because of differences in what they support).
On 22-04-11 04:57, Patrick Scheibe wrote:
...
- The feComposite with mode "Over" works at a first glance quite nice.
The setting Jasper suggested doesn't work like expected. The problem is, that I have overlapping polygons because if there is a "fold" in the "mathmatical"-surface and there are polygons which are invisible because this part of the surface is behind another, Mathematica still exports them. At these places the feComposite doesn't work like Jasper already pointed out. At those places the background polygons shine through the edges of the foreground polygons.
If "over" appears to work quite nice, what's wrong with using it? (It is odd that it apparently works better than normal alpha blending btw, as I think it should be equivalent. So it might indicate a bug in Inkscape.)
Note that this approach can probably be improved a bit, but I doubt it is worth it (given the fact that you're exporting to pdf and that it's not that easy).
- Now that I found the "Filter Editor" with your help (since I'm
technically an absolutely newbie) I looked around and found some other possible solutions to the problem. One would be to use a Dilation-operator. Problem here: you would need a tiny dilation of size around 0.001 (it depends of course on the data). It seems this doesn't work with such sizes; at least not on my machine [1].
The dilation is done on the discrete data. It would be possible to enable support for subpixel sizes, but we haven't done so (and it's slightly dodgy). A size of 1px should work fine though. If that is too visible you could try doing a closing on the composited image. This is done by first doing a dilation and then an erosion (both with the same size), this should remove any small gaps.
- the number of polygons for a surface can easily grow to about 100000
which makes interactive working impossible; meaning Inkscape crashes when the plot is too complex. The plan would be to use the commandline only because my goal is to convert an svg into a pdf [2] and this doesn't require a running GUI.
You might want to try the Cairo branch, it's meant to be a lot faster and less memory hungry. If you are not able to compile it yourself, perhaps someone has a build they can send you? (I only have a Windows build.)
Ok, I have a follow-up question:
In my version of Inkscape I cannot store filters directly. When I create a new filter it is stored automatically in/with a concrete svg file. For every new plot I would have to recreate the filter. Did I overlook something? I saw in a (of course Windoze) tutorial a "Save" button in the filter editor. This button does not exist in my version. Any ideas? Because, when I want to apply a filter through the commandline, I assume it must be listet via "inkscape --verb-list".
Applying filters in this way could indeed be tricky. It might be easier to "hack" something. Given a file like this: <svg> <defs> ... </defs> <g> ... </g> </svg> You should change it to something like this: <svg> <defs> ... <filter id="a" ...> ... </filter> </defs> <g filter="url(#a)"> ... </g> </svg> The filter element can just be copied from a file that contains the right filter.
Cheers Patrick
[1] Ubuntu 9.10, Inkscape 0.47 [2] My main goal is to create "nice and small" pdf versions of my plots. Currently Mathematica creates pdf's which are around 20 MB and need several minutes to be rendered by the Adobe reader. Not acceptable if you want to use them in a LaTeX document.
If you want them "nice and small", this might not be the best way to go around it. From what you told you've got pretty detailed surfaces, those are not going to get any less detailed. It could be that Mathematica saves its pdfs without compression or something, but then it might be better to look for a program that can directly fix that.
Also, as I said at the start of this mail, if you're exporting to pdf, no amount of filtering will help you. In the end it's down to how adobe reader renders the polygons (unless you render everything to a bitmap).
As you apparently want to use these in a LaTeX document, I would recommend exporting as a high resolution png. Probably this alone will be enough to eliminate any visible seams, if not you can always go back to trying out some more tricks. But then it would be better to focus on other approaches than filtering, like writing a script that outsets all shapes by a certain radius (using lib2geom for example).