Hey Mike,

I updated from prince 20151028 to your latest build Prince 20160331 on Ubuntu 14.04 64-bit using http://www.princexml.com/download/prince-20160331-ubuntu14.04-amd64.tar.gz

Before the svgs rendered correctly and became vectors in my output pdf. Now the quality of the svgs (not the woff fonts) in the output odf is terrible. I can't zoom into it without seeing pixels.

I still use the same cli call:

prince 12ec1_1.svg  --page-size='424mm 103mm' --page-margin=0mm -o 12ec1_1.pdf

Pls see attached examples.


Do I need to use additional arguments in the new version or is this a bug?

Thx,
Marcel

1. 12ec1-1.svg‎ 16.2 kB ‎
   Input svg
2. 12ec1-1_bad.pdf‎ 229.2 kB ‎
   bad quality with new version
3. 12ec1-1_good.pdf‎ 363.8 kB ‎
   good quality with old version

There are some SVG filters in the document, and Prince now supports SVG filters so it will rasterise the content to a bitmap image where necessary. Perhaps the filter is not supposed to be actually doing anything in this document, it might be an identity filter that just copies the pixels through unchanged? We may be able to detect this in some cases and avoid rasterisation, but the quickest workaround would be to not apply the unnecessary filter in the first place.

Another option would be to increase the resolution of filtered images with --raster-dpi=300 but this will increase the size of generated PDF files.

Ah, ok, understood!
I suggest you detect the easy cases for feComponentTransfer, where slope="1" (or not exists) and intercept="0" (or not exists).

<filter color-interpolation-filters="sRGB">

  <! -- brightness -->
  <feComponentTransfer>
    <feFuncR type="linear" slope="1"></feFuncR>
    <feFuncG type="linear" slope="1"></feFuncG>
    <feFuncB type="linear" slope="1"></feFuncB> 
  </feComponentTransfer>

  <! -- contrast -->
  <feComponentTransfer>
    <feFuncR type="linear" slope="1" intercept="0"></feFuncR>
    <feFuncG type="linear" slope="1" intercept="0"></feFuncG>
    <feFuncB type="linear" slope="1" intercept="0"></feFuncB>
  </feComponentTransfer>

</filter>

Thx for your quick response!
Marcel

We can check this. There might be complications if it (theoretically) involves transforming back and forth between linear RGB and sRGB, I'm not sure.

I think in my cases this are additiv operations and it should behave as expected.
But I followed your advise and implemented it at our end. Therefore this issue is solved for me. Thx.

The latest builds now avoid unnecessary rasterisation for identity filters.