Printing SVG graphics that use clipping masks - svg

I've created a detailed infographic that makes good use of clipping masks similar to the example seen here http://bl.ocks.org/enjalot/1503463. However, when I try to print my infographic, all the masked blocks become solid colored blocks and the mask seems to be ignored. Is there any way to fix this?
The only relavent post I found was Clipping path in SVG not working in Safari where they've forgone the using the <use> element.

Related

Edge value problems when generating bitmaps using SVG + CairoSVG

Me and my team have problems with generating bitmaps out of polygons. We've tried a few different solutions in order to generate polygons sufficiently fast and have found generating SVG paths and then using CairoSVG to be the best solution for us. We are using the even-odd rule to fill the polygons. I apologies if I'm describing everything in an incorrect way in terms of vocabulary, I'm new to SVG. The pathes are created as:
path_entry = f'<path fill="rgb{rgb_color}" fill-rule="evenodd" d="{svg_path}"/>'
With header
<svg
xmlnsXlink="http://www.w3.org/2000/svg"
preserveAspectRatio="xMinYMin meet"
style="color:green;"
>
We only allow the bitmap to have a set of color values. The value of a pixel should be that of the polygon which it's inside. A problem we've encountered is that the edges of the polygons "splits" pixels, i.e a pixel can be both on the edge/inside of polygon A and polygon B. See the image below where the edge between the black, green and grey area gets a mixed color.
We've currently solved this by finding each pixel that doesn't have an allowed color. We then use numpy roll to fill the value of these pixels with the value of its neighbours according to a solution found on this site.
for shift in (-1,1):
for axis in (0,1):
a_shifted=np.roll(bitmap_only_correct_colors,shift=shift,axis=axis)
idx=~a_shifted.mask * bitmap_only_correct_colors.mask
bitmap_only_correct_colors[idx]=a_shifted[idx]
The problem with this solution is thin diagonal polygons, 1-2 pixels thick. All pixels of these polygons get the mixed value and are therefor removed. This causes the thin polygons to be partly removed creating dotted lines instead of full lines, see the image below.
My question is: Can we solve this problem with the edges of the polygons not getting fixed values in another way? The best solution would be to add some kind of setting to the SVG-Document before generating the images.
Thank you!
Turn off anti-aliasing i.e. set shape-rendering="crispEdges" See the SVG specification for more details about this CSS property.

Move Raphael path with png fill image, without breaking image in IE or moving image relative to element?

There are three basic ways to move a path in Raphael.
If that path has a fill image that has PNG transparency, and you need IE8 (VML), all three are flawed.
JSBin demo
If you use a simple transform...
path1.animate({transform: 't20,100'},1000);
...then in IE8, the png transparency in the fill breaks and translucent pixels turn black. Edges become pixelated and ugly, and depending on the image you might get a scuffy black outline around the translucent edge of the image. Not good, and there doesn't seem to be any reliable way to fix this after the event.
Sometimes, inconsistently, the background image also doesn't stay relative to the element (more on that below).
If you animate the path attribute, for example like this:
path2.animate({path: Raphael.transformPath( path2.attr('path'), 't100,20') },1000);
...IE8 doesn't wreck the image background. However, the fix for making background images relative to the element not the paper does not work with this method (and various ways I've tried to bodge it using improved background image offset with an additional "M-20,-20" element don't seem to work), and I can't find any way to make that work either.
Also, just having lots of transformations on the go can break the delicate IE8 bug the background image fix depends on in VML mode, causing the background to move. This seems to be inconsistent - with the JSBin above, in IE8, sometimes they all move, sometimes only the top one moves.
If you use translate...
path3.translate(42,42);
...the results are the same as transform (presumably both use the same translate functions).
With Raphael image elements, it's possible to fix this broken alpha by applying opacity with the transform in an attr or animate call. This doesn't work with path fills. Also, turning off the fill and resetting it from the original URL string doesn't remove the broken alpha contamination. You can see this in this demo.
So, I'm looking for a way to move a Raphael path that has a background image that has PNG transparency that a) keeps the image relative to the element, consistently and b) doesn't wreck the PNG transparency in IE8 by turning partial transparency into pixelated black.
Similar problems occur with any form of transformation - such as scale, rotate etc.
I can't find any good answer to this: the closest I've found is an ugly but functional workaround for IE8 transform (wrapped in if(Raphael.type=='VML')s so you don't spoil things for real browsers):
Before doing any transform to anything that has an alpha transparency PNG / pattern fill, remove the pattern fill (path.attr({fill:'none'});), storing the fill setting like path.data('fill',path.attr('fill'));
After the transform, asynchronously (e.g. wrapped in setTimeout(function(){ })) re-apply the fill e.g. path.attr({fill: path.data('fill')});
The crucial thing seems to be: the fill must not be applied when the transform occurs, else it'll be ruined forever, even if you remove and re-apply it. Be careful with the timing on this - it mustn't be possible for the fill to re-apply before the transform completes (e.g. watch out for race conditions with animations or other async processes).
If you're animating a transform, your options seem to be to either:
Clear the fill before the animation, just accept that there will be no fill while the animation takes place, and re-set in a callback after the animation completes
Implement your own animation handler than removes and re-applies the fill before and after every frame (this, of course, risks being a performance nightmare).

What is the correct way to achieve intersection of multiple clip paths?

As described in another post, I am trying to recreate an SVG from vector graphics commands in a PDF and I am facing some difficulty in the part where I need to intersect a set of clip paths. For instance, the raw SVG has a few clip path elements line #16 which need to be intersected and applied on the rectangle fill (line #17) to obtain what looks like this: .
I am not clear about the correct and the best way to achieve intersection of multiple clip paths in an SVG. I wasn't able to find much information about this on the web except this one, going by which I came up with this SVG where I introduce a sequence of additional clipPath elements which try to intersect the current intersection with the next original clipPath to be added to the intersection set. This approach seems rather inelegant to me. Besides, that SVG doesn't seem to work on some versions of Firefox (ESR 17.x) though it renders the expected result on Firefox 5, Chrome and IE. Is there something wrong with the SVG? Or even if it is correct, is there a simpler/better way to achieve the intersection?
The way you've done it seens reasonable. There's a w3c example in the testsuite.

Rollover overlays with SVG

i want to acheive the effect on this page using SVG. As you can see it uses a series of PNG transparent overlays when the user mouses over a polygonal hotspot drawn on a product.
What i want to achieve is the same thing with SVG, but without messing about with creating a load of PNGs, so that when the user mouses over an area the transparent shape (with link on it) appears over the top. The SVG shape would be built from a set of coordinates exactly as a polygonal hotspot would on an image map.
So i guess my first question is, can this be done with plain old SVG or do i need to use something like Raphael to achieve this? Never seen this effect before with SVG so if anyone has an example like that would be very useful.
Thanks in advance.
There are several ways to get this effect with plain old SVG. Probably the simplest is to use CSS within the SVG. For example:
<style>
.overlay:hover
{
opacity: 0.5;
}
</style>
<svg>
<a xlink:href="http://www.wherever/you/want/to/link/to.com">
<path class="overlay" d="Coordinates of your shape..." />
</a>
</svg>
I've written about various other methods at:
http://www.petercollingridge.co.uk/data-visualisation/mouseover-effects-svgs
Yes it can be done with SVG only, with or without javascript.
One way to get the effect would be to overlay a white semi-transparent path on top of the image that you want to whiten. Another way would be to use an SVG filter to process the image directly, similar to what I've done here or here to recolor a PNG (view page source and feel free to reuse that in any way you like).
You'll want to make use of the 'pointer-events' property most likely. Here's an example showing how to detect mouse-events on the fill and/or stroke of an svg shape, even if the shape is invisible.

Applying SVG filter to background image

I am attempting to apply an SVG filter (Gaussian blur) to only a portion of an image (i.e. the background). I have achieved the effect by appending a clipped SVG image with Gaussian blur applied at the same position (to make it appear like the Gaussian blur is applied to the original image).
This is obviously inefficient and I'm looking for a better method. After reading some SVG docs and examples it looks like the enable-background attribute is needed but I would greatly appreciate some help on how to actually implement it!
Edit:
An example of the effect I'm looking for: http://img695.imageshack.us/img695/92/chromeblur.png
Here is a good description of how it should work in SVG
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/Filters2.htm
But SVG support is still incomplete in all common browsers. Especially the filter effects on backgrounds using the in="BackgroundImage" and enable-background attributes are not supported by any common browser.

Resources