plot issues -> favor pdfcairo [new changeset]

[Ben Abbott]

On Jun 7, 2009, at 3:13 PM, Benjamin Lindner wrote:

> 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

I did find a problem with the prior changeset (new bug), but I don't  
understand why it wouldn't apply for you. In any event, try the  
attached version.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset.patch
Type: application/octet-stream
Size: 8569 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090608/86cbe83b/attachment.obj 
-------------- next part --------------