plot issues -> favor pdfcairo

[Ben Abbott]

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).

Ben

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