Re: Limitation of recording surface

On Thursday 05 February 2015 08:13:34 Bernhard R. Fischer wrote:
> On Wednesday 04 February 2015 23:11:24 Adrian Johnson wrote:
> > On 04/02/15 20:05, Bernhard R. Fischer wrote:
> > > Hi!
> > > 
> > > I'm developing Smrender which is a chart renderer for OSM data and I use
> > > cairographics for it. Those charts are highly complex and contain a huge
> > > amount of vector data.
> > > 
> > > Internally, everything is rendered to a recording surface which is
> > > finally
> > > "painted" to a PDF surface (or other formats).
> > > 
> > > 
> > > I found out that with some amount of input data the PDF is degraded to a
> > > raster image instead of vector image.
> > > 
> > > Is there any known limit in the recording surface or in the PDF surface
> > > which causes this behavior? Is there any possibility to change this or
> > > do
> > > you have any suggestions what I can do to avoid this?
> > 
> > No. As long you do not use operators unsupported by PDF it should not be
> > rasterized. If you are only using CAIRO_OPERATOR_OVER and seeing
> > rasterization in pdf it is likely a bug.
> 
> I use CAIRO_OPERATOR_OVER and CAIRO_OPERATOR_CLEAR but nothing else. I'll
> try to track down the problem more specifically.


I solved the problem.
What I did was to cut out holes of a polygon in a group by using 
CAIRO_OPERATOR_CLEAR and then painted the group to the PDF surface 
(pop_group_to_source(), paint()).

Although this works fine with image surfaces it seems that this operation is 
not supported (or not implemented correctly) in the PDF backend as well as in 
the SVG backend.

Interestingly, I found out that if the recording surface is painted and saved 
twice that the second output file differs from the first one (see code example 
below). In my opinion this should not happen.

Nevertheless, the rasterization is a matter of the PDF surface and not the 
recording surface. It behaves in the same way as described without the 
intermediate recording surface but using a PDF surface directly.


I comiled the following example to demonstrate my observations. Please note 
that I also have a solution which is to use sub-paths before fill() instead of 
using fill() twice, one to paint and one to cut the hole.

http://www.abenteuerland.at/download/eagle/cairo_rec_1.c
(#define NOT_WORKING to show rasterization and comment it out tho show the 
working version)

Best regards,
Bernhard

-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABCAAGBQJU2OKsAAoJEB2of8NcX/1HrhIIAMCvy75WOT+b7bq/oIwqEvsb
64JtQni6PS0Oxux4TGCw4ufjZNMF31HZcvLwlt5isNGp/EHfow3aRdNV2cPVg7vd
BhTqRkkTLRMsbyKvm1KefrbhNmrPGeDJHld4MLz7jeKFWi0CK6+KTxHxXCA+s+JC
FT6xyWDu4ipcBBWxZX3Ts41eubDO+Bub0Hp0pVwWOvbbqeOtkRCnBtiQ9Kkd+zSs
CfFghfTgJngsvvPhrA5RwQ78VmLz6XF2GMpIoF9i1r4D2PQFPkudeEQwPBD79PqP
9X5wJjVOXDmCf3LbR0a/dlXYkpbYFmf0YvJ9ph/luR98MWWNDRU2xBioWpXkLPo=
=MoHz
-----END PGP SIGNATURE-----