Dear developers, thanks for the great app!

I am running: prince file.svg -o file.pdf

The issue I am reporting is that the resulting PDF contains an embedded image which is far from identical to the original image embedded in SVG (the two screenshots are provided in attachments). Looks like the image is being rasterized at low resolution when it shouldn't be rasterized at all: it can be embedded without loss of quality via /FlateDecode.

The issue is most evident in prince-bug.svg (attached), where an apparent resolution of the rasterized image embedded in PDF looks like 100-150dpi. prince-bug-minimal.svg is my attempt to minimally reproduce the problem, and in this case the embedded image in PDF looks fine.

In any case, rasterization is unnecessary in all such cases.

P.S.

And also, it seem like Price XML sets the <interpolate> tag for the images that it embeds in PDF. I may be subjective here, but it seems like it's both unnecessary and detrimental to the visual quality of the result. It was mostly used in the old days when Adobe Reader used a simplistic algorithm for bitmap image rendering (neares-neighbour) with bad quality results, and turning on the <interpolate> tag seemed to help somewhat. It has long fallen out of fashion since then. Again, this is, obviously, not a bug in Price XML, it's just my opinion on the feature.

1. prince-bug-minimal.svg.zip‎ 15.7 kB
2. prince-bug.svg.zip‎ 23.6 kB ‎
   prince-bug.svg
3. prince-image-embedded-in-pdf (screenshot).png‎ 27.0 kB
4. prince-original-image-embedded-in-svg (screenshot).png‎ 22.9 kB

The tool that generates the SVG embeds the image in a peculiar way: using a filled <rect> with a soft mask that uses a <symbol> that contains a raster image that encodes the alpha channel. It is probably so that the foreground color of the image can be controlled by changing the fill color of the rectangle.

Thanks for the prompt reply! It makes a lot of sense, actually. However:

1) what makes you think the mask is "soft"? The bitmap contains a bitonal (black/white) image, and also the pixel dimensions of the mask are equal to the pixel dimensions of the image, so that's as sharp as it gets in terms of the edges of the image that should be rendered;
2) Google Chrome (headless) seems to convert this SVG to PDF preserving resolution/ sharpness of the edges (see attachment).

1. prince-bug-chrome.pdf‎ 32.3 kB

The SVG 'mask' property and <mask> elements corresponds to "Soft Masks" in PDF, that's all.

Prince is almost able to avoid re-rasterising the mask in this case, so it is something that could be improved in the future. A workaround for now is to increase the resolution at which the mask is rasterised:

@prince-pdf { prince-filter-resolution: 300dpi; }

Thanks once more, wangp! Workaround confirmed. Waiting for the future)

Today we have released a new latest build that avoids unnecessarily re-rasterising some soft masks.