plot issues

Benjamin Lindner lindnerben at gmx.net
Fri Jun 5 13:12:52 CDT 2009


Ethan Merritt wrote:
> On Friday 05 June 2009, Ben Abbott wrote:
> 
>>>> Petr, what are the benefits of the pdfcairo and pngcairo terminals  
>>>> over the pdf and png terminals?
> 
> Aside from licensing issues for PDFLib, using cairo to generate the plots
> allows antialiasing, transparency, and UTF-8 support.  

This may be a sutpid question, but what should a vector-based graphics 
description support antialiasing for?
An output device, yes, but the graphics language?

>> Are there any license problems with the plain png terminal, or is it  
>> just the pdf?
> 
> The "plain png" terminal has not been supported for about 8 years now.
> Instead the default is to use libgd, and the newer option is to use
> cairo.  None of these has any licensing issues that I am aware of.
>  
>> Presently, when the pdf terminal is specified, the print() function  
>> checks with gnuplot to determine if the "pdf" terminal is supported.  
>> If not, or unknown, print() checks for the presence of ghostscript. If  
>> present, the ps terminal is used to produce a ps-file and then  
>> ghostscript is used to convert to pdf.
> 
> Going through an intermediate postscript file is non-optimal, because
> PostScript itself does not support transparency or UTF-8 characters.
> At least from the perspective of plot quality, this is probably the
> least satisfactory of several options.
> It would be better to use either pdfcairo or the brand new tikz terminal.

pdfcairo might be superior if you require transparency and UTF-8, 
granted, but the quality of the generated output is disappointing 
compared to pdf via postscript.
I do a lot of image plots and found that the resulting file sizes with 
the pdfcairo terminal are 4-8 times larger than a ps->pdf output. Also 
you don't have good control over font selection, which is IMO a 
knock-out criteria when doing high-quality plots for e.g. latex inclusion.

But it naturally involves an indirect step requiring ghostscript, thus 
being slightly more complicated than a simple pdfcairo output.

So for the sake of simplicity it'll be good if octave's print would 
support the pdfcairo terminal, and for applications where quality detail 
matters (and you don't need features postscript can't give you) the 
ps-to-pdf-via-ghostscript is available.

I also like the idea of the user being able to choose the method of pdf 
creation, but I wouldn't know how to implement it ad hoc.

benjamin


More information about the Bug-octave mailing list