Re: plot issues -> favor pdfcairo

[Ben A. <bpa...@ma...>]

On Jun 6, 2009, at 7:49 AM, Benjamin Lindner wrote:

> Ben Abbott wrote:
>> On Jun 5, 2009, at 4:08 PM, Ethan Merritt wrote:
>>> On Friday 05 June 2009 11:12:52 Benjamin Lindner wrote:
>>>> 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?
>>>
>>> Ben asked about both pdfcairo and pngcairo.
>>> The anti-aliasing is an issue for png, not for pdf.
>>> Conversely, the transparency support is an issue for pdf but not  
>>> for png.
>>>
>>>> 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.
>>>
>>> All I can say is that I have had the opposite experience.
>>> Maybe that's because I work in a UTF environment and need support
>>> for CJK character sets.  PostScript is basically hopeless for those.
>>> There are some very fragile workarounds, but they are so  
>>> installation-
>>> specific that it doesn't work to build scripts or work flow around  
>>> them.
>>>
>>> For latex inclusion, ps2pdf or direct PDF generation should be  
>>> exactly
>>> the same, and subject to the same limitations of whatever converted
>>> Computer Modern fonts you are using.  If that is a primary concern,
>>> then using one of the latex-based terminals directly is a better  
>>> bet.
>>>
>>>    Ethan
>> It doesn't appear to me that there is one solution that is  
>> preferred over the other in all cases.
>> I'll propose the following, and encourage all to comment.
>> -----------
>> 1) if "pdfcairo" is present => use "set term pdfcairo ..."
>> 2) if "pdf" is present => use "set term pdf ..."
>> 3) if neither => use "set term postscript ..." and then convert  
>> using ghostscript
>> -----------
>
> Sounds very reasonable to me.
>
>> Although I'm a big LaTeX user, I elevated pdfcairo over pdf for the  
>> transparency feature.
>> Similarly for png
>> -----------
>> 1) if "pngcairo" is present => use "set term pngcairo ..."
>> 2) if "png" is present => use "set term png ..."
>> 3) if neither => use "set term postscript eps ..." and then convert  
>> using ghostscript
>> -----------
>
> same as above
>
>> For LaTeX, I will soon be adding support for the Lua/TikZ terminal.  
>> Its rendering is a bit slow, but produces excellent results for  
>> both latex and pdflatex.
>> The solutions above will only work well for gnuplot 4.3+. Prior to  
>> that the variable GPVAL_TERMINALS does not exist, and octave has no  
>> manner to check for the existence of specific terminals.
>
> For windows platform this is OK, since a working console application  
> is only possible with 4.3+
> Also interactive zooming with piped gnuplot works only with 4.3+
>
> benjamin

Great!

I've attached a changeset for the pdf part. It is combined with a  
changeset for forcing mono rendering (there is some problem with  
rgb2gray that has delayed me in pushing that change).

In any event, I'd appreciated confirmation form linux and window's  
users that this chageset works correctly.

Ben