[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: plot issues -> favor pdfcairo [new changeset]
From: |
Ben Abbott |
Subject: |
Re: plot issues -> favor pdfcairo [new changeset] |
Date: |
Tue, 09 Jun 2009 10:13:23 -0400 |
On Tuesday, June 09, 2009, at 09:26AM, "Benjamin Lindner" <address@hidden>
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
>
Thanks for the feedback. I'll fix this later today.
Ben
- Re: plot issues -> favor pdfcairo, Ben Abbott, 2009/06/07
- Re: plot issues -> favor pdfcairo, Benjamin Lindner, 2009/06/07
- Re: plot issues -> favor pdfcairo [new changeset], Ben Abbott, 2009/06/08
- Re: plot issues -> favor pdfcairo [new changeset], Benjamin Lindner, 2009/06/09
- Re: plot issues -> favor pdfcairo [new changeset],
Ben Abbott <=
- Re: plot issues -> favor pdfcairo [new changeset 2], Ben Abbott, 2009/06/09
- Re: plot issues -> favor pdfcairo [new changeset 2], Benjamin Lindner, 2009/06/10
- Re: plot issues -> favor pdfcairo [new changeset 2], Ben Abbott, 2009/06/10
- Re: plot issues -> favor pdfcairo [new changeset 2], Benjamin Lindner, 2009/06/10
- Re: plot issues -> favor pdfcairo [new changeset 2], Ben Abbott, 2009/06/10
- Re: plot issues -> favor pdfcairo [new changeset 2], Benjamin Lindner, 2009/06/10
- Re: plot issues -> favor pdfcairo [new changeset 2], Ethan Merritt, 2009/06/10
- Re: plot issues -> favor pdfcairo [new changeset 2], Benjamin Lindner, 2009/06/15
- Re: plot issues -> favor pdfcairo [new changeset 2], Ben Abbott, 2009/06/15
- 4.4.alpha source [Was Re: plot issues -> favor pdfcairo [new changeset 2]], Ethan Merritt (sfeam), 2009/06/15