plot issues -> favor pdfcairo [new changeset 2]

[Ben Abbott]

On Jun 9, 2009, at 7:27 PM, Ben Abbott wrote:

>
> On Jun 9, 2009, at 9:26 AM, Benjamin Lindner wrote:
>
>> 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
>
> Please try the attached.
>
> Ben
>
> <changeset.patch>

The changeset has been pushed.

	http://hg.savannah.gnu.org/hgweb/octave/rev/4f96a7770492

Ben

>