[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: plot issues -> favor pdfcairo [new changeset 2]
From: |
Ben Abbott |
Subject: |
Re: plot issues -> favor pdfcairo [new changeset 2] |
Date: |
Wed, 10 Jun 2009 09:58:13 -0400 |
On Wednesday, June 10, 2009, at 09:11AM, "Benjamin Lindner" <address@hidden>
wrote:
>Ben Abbott wrote:
>>
>> On Jun 10, 2009, at 5:02 AM, Benjamin Lindner wrote:
>>
>>> 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.
>>>
>>> This one looks good.
>>> with
>>>
>>> plot(0:0.1:10, sin(0:0.1:10), "@-;sin;", 0:0.1:10, cos(0:0.1:10),
>>> "@-;cos;");
>>> print -depsc2 -debug:print.eps.log test.eps
>>> print -dpsc2 -debug:print.ps.log test.ps
>>> print -dpng -debug:print.png.log test.png
>>> print -demf -debug:print.emf.log test.emf
>>> print -dpdf -debug:print.pdf.log test.pdf
>>>
>>> I get now a pdfcairo and pngcairo output.
>>>
>>> However the pdfcairo output seems buggy, since it consists of 3 pages:
>>> a blank first page, a second page with the expected graph and a blank
>>> third page.
>>> Hmm, looks like a problem with gnuplot I guess.
>>>
>>> benjamin
>>
>> What version of gnuplot are you running?
>>
>> I can run 4.2.2, 4.2.3, 4.2.4, 4.2,5 and 4.3.0 (current developers
>> sources). If I can confirm the same behavior, I'll add
>> "pdfcairo_is_broken" to __gnuplot_has_feature__ and switch to
>> ghostrscript for that instance.
>>
>
>I have a 4.3.0 version, namely the CVS 2008-11-21 snapshot.
>
>benjamin
Ok. I'm running developers sources that are less than a week old. I don't see
the problem you reported.
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, 2009/06/09
- 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 <=
- 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
- Re: plot issues -> favor pdfcairo [new changeset 2], Ben Abbott, 2009/06/11