my goal was to understand the behavior.
I wanted to keep vector graphics for my plots and have them as pdf (for
using it in say latex). Rasterizing them into nice looking images was
never a problem but then all the labels which are text and the axes and
axes-ticks which are perfect lines are rasterized too. I wanted to keep
them as text and lines.
My current solution is the following:
Mathematica exports the svg polygon directives with stroke=none. I just
fixed that to stroke=0.5px and set the line color to the line color of
the corresponding polygon.
This gives really nice results. Then I use inkscape to convert this to a
I see that using inkscape only for converting svg to pdf is a bit
overkill (although I only use the commandline). Maybe it's better to
take for instance the cairo lib and write a program which does the
By the way: Does Inkscape use Cairo to create the rendered views that
you see on the screen or has it its own implementation?
On Tue, 2011-04-26 at 09:49 +0200, Jasper van de Gronde wrote:
> 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 .
> 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  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
> > 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:
> You should change it to something like this:
> <filter id="a" ...>
> <g filter="url(#a)">
> The filter element can just be copied from a file that contains the
> right filter.
> > Cheers
> > Patrick
> >  Ubuntu 9.10, Inkscape 0.47
> >  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).