| 1 |
>>>>> "FR" == Francesco R <vivo75@×××××.com> writes: |
| 2 |
|
| 3 |
FR> Last time (many moons ago) I've checked cairo did not generated pdf |
| 4 |
FR> it did generated raster images and wrapped them in a thin pdf layer. |
| 5 |
FR> pdflib is generating vector pdf which is a different thing. |
| 6 |
|
| 7 |
Cairo will fall back to an image for anything which cannot be described |
| 8 |
by whichever output driver one uses. Transparency will cause that when |
| 9 |
generating PostScript, for instance, because PostScript does not support |
| 10 |
transparency. But there are few—if any—ops which cairo supports which |
| 11 |
are not also supported by pdf. |
| 12 |
|
| 13 |
Gnuplot’s cairopdf terminal generates vector output. One might argue |
| 14 |
that it is not optimal, but only because it uses line segments rather |
| 15 |
than cubic curves to approximate graphs. (Ie, it uses cairo’s lineto |
| 16 |
rather than curveto functions.) |
| 17 |
|
| 18 |
But so do gnuplot’s native terminals (I tested postscript and svg.) |
| 19 |
|
| 20 |
That is just how gnuplot draws. |
| 21 |
|
| 22 |
I’d still keep the pdf USE flag with its current meaning; users may have |
| 23 |
existing gnuplot scripts which use gnuplot’s pdf terminal and/or apps |
| 24 |
which generate such scripts. Unless, of course, a patch is added which |
| 25 |
makes «set term pdf» an alias for «set term cairopdf». |
| 26 |
|
| 27 |
-JimC |
| 28 |
-- |
| 29 |
James Cloos <cloos@×××××××.com> OpenPGP: 1024D/ED7DAEA6 |
Archives