|
From: | Ben Abbott |
Subject: | Re: plot issues -> favor pdfcairo [new changeset] |
Date: | Mon, 08 Jun 2009 18:47:43 -0400 |
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: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.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:It doesn't appear to me that there is one solution that is preferred over the other in all cases.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 terminalsover the pdf and png terminals?Aside from licensing issues for PDFLib, using cairo to generate the plotsallows antialiasing, transparency, and UTF-8 support.This may be a sutpid question, but what should a vector-based graphicsdescription 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 disappointingcompared 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. Alsoyou don't have good control over font selection, which is IMO aknock-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 supportfor 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.EthanI'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 aboveFor 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+ benjaminGreat!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.BenI'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.
changeset.patch
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |