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