plot issues -> favor pdfcairo

[Benjamin Lindner]

Ben Abbott wrote:
> On Jun 6, 2009, at 10:38 AM, Ben Abbott wrote:
> 
>> 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
> 
> I've rolled up all the changesets for these plot issues. The attached 
> must be applied to the current sources. With this change applied, the 
> print command will favor the cairo terminals and will properly render a 
> gray-scale image when the -mono option is specified.
> 
> I'd appreciate some testing to make sure there are no surprises.
> 
> I also  noticed we've been on bug list. I've moved this over to the 
> maintainers list (I should have done that many emails ago).
> 

Hmm, I tried to import your changeset, but it fails for all hunks.
My tip is 9305:52b4d82e5b4f from http://www.octave.org/hg/octave

benjamin