plot issues -> favor pdfcairo [new changeset 2]
Ben Abbott
bpabbott at mac.com
Wed Jun 10 06:43:41 CDT 2009
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.
Ben
More information about the Octave-maintainers
mailing list