Re: Polishing the new PDF terminal (cairopdf)

[<tim...@en...>]

Ethan Merritt wrote:
> I'd like to collect comments and suggestions on any rough edges
> marring the new cairopdf terminal driver.
>
> I know of 3 problems, 2 of which are illustrated by 
> fillbetween.dem
>
> 1) The pattern fill scales as a bitmap rather than as
>    a vector pattern.  This is ugly at high resolution.
>    If we can't make the vector pattern scale correctly,
>    then in monochrome mode we should probably replace
>    the pattern fill with incremental solid shading.
>    pattern 1 = no fill
>    pattern 2 = black
>    pattern 3 = 50% grey
>    etc
>
> 2) The fill area is not clipped to the plot boundaries.
>    This puzzles me, because I thought that the clipping
>    was done by the core code.  But other terminals do not
>    show this, so...
>
> The 3rd problem may or may not be a gnuplot bug.
>
> 3) Under some conditions the entire plot has a black background.
>    I only see this on machines with very different versions of
>    cairo/pango/kde/kpdf/... so I'm having difficulty figuring
>    out which program or library  is at fault.  But even if it is
>    a viewer bug, there may still be a fix to gnuplot that would
>    avoid triggering it
>
> Missing features:
>
> 4) There should be a dashlength option (similar to postscript)
>
> 5) Circles (e.g. point types 6 and 7) look jagged.
>    This is ultimately the fault of the cairo library, but perhaps
>    we could work around it by scaling a well-hinted character
>    glyph instead?
>
> Any other observations?
>
>   
Hi Ethan,

I am back to a usual internet connection, I'll try to provide some 
answers to your questions.

1) This is a limitation in pdf support in current cairo. Some operations 
are not fully implemented and so bitmap fallbacks are used instead. 
Adrian Johnson is working on it, and his cairo repository is available 
here: 
http://gitweb.freedesktop.org/?p=users/ajohnson/cairo.git;a=summary 
(branch pdf-meta-surface-pattern)

With it, the patterns are vectorized. However, this currently shows 
another problem: pattern tiles have seams between each other, so it's 
not so great. I am sure this will be worked out in the future.

2) I cannot reproduce this. For me, the fill area is properly clipped.

3) Again, I don't remember having seen this.

4) I saw that you implemented it. Maybe some more text in the doc would 
be interesting... and the same implementation in wxt ;) In general I 
think it would be good to keep the two terminals very close to each 
other so that testing is easier.

5) I don't see this. For me, those circles are perfect. Instead of 
blaming cairo, I would blame the pdf renderer, which may or may not do 
some antialiasing. I am using evince 0.8.3 with poppler 0.5.9. kpdf 
0.5.7 (kde 3.5.7) gives nice circles too.


As for my personal observations, I am worried by one thing really: the 
bitmap fallbacks for the pm3d polygons. This is due to the composition 
operator I am using in the cairo code to draw the polygons. With the 
default operator (CAIRO_OPERATOR_OVER), the polygons show seams between 
them, even though their coordinates are contiguous. This is also what 
happens for the current svg (non-cairo) terminal, for aquaterm, and 
maybe others. To workaround that, I am using CAIRO_OPERATOR_SATURATE and 
draw the polygons front to back. This gives in wxt a nice seamless pm3d 
surface. But for the cairopdf terminal, it results in a bitmap fallback, 
as you see currently with the patterns. So my question is the following: 
do we want a seamless but bitmapped pm3d surface (until 
CAIRO_OPERATOR_SATURATE is implemented in cairo pdf backend) or a 
vectorized pm3d surface, but with seams between the polygons ?

Best regards,

Timothée