Re: Octave 3.1.55: printing to pdf

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 05 April 2009, Ben Abbott wrote:
> 
> On Apr 5, 2009, at 3:47 AM, Petr Mikulik wrote:
> 
> > Printing to pdf (via gnuplot backend) is broken in Octave 3.1.55  
> > even though
> > gnuplot accepts "set term pdf" via "pdfcairo" terminal.
> >
> >
> >> plot(1:100); print a.pdf -dpdf
> >
> > error: gnuplot_drawnow: the gnuplot terminal, "pdf", is not available.
> > error: called from:
> > error:
> > /opt/octave/octave-3.1.55/share/octave/3.1.55/m/plot/ 
> > gnuplot_drawnow.m at
> > line 72, column 7
> >
> >
> > It seems that gnuplot_drawnow.m requires exact match of terminal  
> > names in
> > 3.1.55. However, gnuplot names the pdf terminal "pdf" or "pdfcairo"
> > according to the library it was compiled against. In both cases "set  
> > term
> > pdf" works.
> >
> > I think gnuplot_drawnow.m should test presence of "pdfcairo" if  
> > "pdf" has
> > not been found.
> >
> > If I try
> > 	print zz.png -dpngcairo
> > 	print zz.pdf -dpdfcairo
> > it produces these two files:
> > 	pngcairo:zz.png
> > 	pdfcairo:zz.pdf
> > Why the prefix there?
> >
> > ---
> > PM
> 
> Petr,
> 
> For "set term png" if there is no "png" present does gnuplot  
> substitute "pngcairo" as well?

yes

> I notice the cairo terminals default options are different from the  
> non-cairo terminals. Specifically, there is no default font-name  
> specified, in GPVAL_TERMOPTIONS, for the cairo terminals. This will  
> interfere with the rendering of different font-sizes when the  
> anonymous font-name "*" is associated to an Octave text object.

The cairo terminals default to font "Sans".
Why does this make a difference?
Would you like this to be echoed back by "show term"?
All gnuplot terminals should accept a font-size request with a blank font
name as referring to the current (perhaps default) font.
E.g.
     set term png enhanced font ",11"
     set title "Big Title" font ",20"
should give you the default font in size 11 points, and a title in the
same font with size 20 points.

 
> The prefixes "pngcairo" and "pdfcairo" prefixes are due to how print.m  
> has been implemented.
> 
> When the specified device does not match an explicit list, Octave  
> assumes that "convert" is to be used to convert the image to the  
> specified format. Octave uses eps as the basis for converting to other  
> formats.
> 
> As "pdfcairo" and "pngcairo" are not presently among the devices  
> supported by Ocave, the current implementation relies upon  
> "convert" ... which is obviously not what you intend, and does not  
> produce a sensible result.

I don't follow this.  Octave should not care how gnuplot chooses to
produce a PNG file.  There are at least 3 possible drivers that gnuplot
might use (the now obsolete libpng-based png driver, the libgd-based
png driver, and the cairo-based png driver).  In each case gnuplot
accepts "set term png", exactly so that the calling script or interactive
user does not need to know the details of that particular gnuplot 
installation.  

It is true, of course, that the obsolete driver never supported many of
the recent options like variable fonts and rgb colors,
but the libgd and cairo implementations are pretty similar in terms of
what they support.  In fact if you encounter an issue where they are
incompatible, I would appreciate a bug report.

> In any event, I'm planning to add support the Lua/TikZ terminal soon.  
> It would make sense for me to include the cairo terminals as well.

You should not have to do anything at all to support the cairo terminals.
Just issue the "set term png" or "set term pdf" commands as usual.

The only reason for ever saying "set term pngcairo" is if you are trying
to force a choice between two alternative png drivers in the same gnuplot
executable.  I think that is more of interest to gnuplot developers than
to outside users.  

-- 
Ethan A Merritt