plot issues -> favor pdfcairo [new changeset]

[Benjamin Lindner]

Ben Abbott wrote:
> 
> 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.

Argh, stupid CRLF line endings mess.
Got the changeset to apply.
However, it does not work as expected.

I have a gnuplot version, which has the pdfcairo and pngcairo terminals 
and has the png terminal.
Printing to pdf as "print -dpdf" now still invokes ghostscript.
I believe I can guess where the problem is.

       available_terminals = __gnuplot_get_var__ (gcf, "GPVAL_TERMINALS");
       available_terminals = regexp (available_terminals, "\\b\\w+\\b", 
"match");
       gnuplot_supports_term = any (strcmp (available_terminals, termn));

This yields for the gnuplot under test a cell array available_terminals 
which includes a terminal "pdfcairo" but does *not* include a terminal 
"pdf". Thus a "print -dpdf" will yield gnuplot_supports_term=false, and 
then the check for the cairo terminals is never done.

I guess the same will happen if gnuplot supports pngcairo but does not 
support the png terminal.

The decision logic is the wrong way round.

benjamin