Re: [changeset] print.m (matlab compatibility)

[Ben Abbott]

On Mar 10, 2009, at 5:35 AM, John W. Eaton wrote:

> On  9-Mar-2009, Ben Abbott wrote:
>
> | The attached changeset introduces Matlab compatible printing.
> |
> | The positioning of the tick-labels, axes-labels, and title has also
> | been improved (these seemingly separate features are intertwined).
> |
> | In any event, some examples exercising the new functionality (note
> | these use default terminal fonts (*). If you encounter a problem,  
> let
> | me know).
> |
> | (1) ex: 6x4.5in figure of surfl(peaks) in the formats; eps, pdf, png
> | at screen resolution, and png at 300dpi.
> |
> | set (0, "defaultaxesfontsize", 12)
> | set (0, "defaultetxtfontsize", 12)
> | set (0, "defaultaxesfontname", "*")
> | set (0, "defaultetxtfontname", "*")
> | figure (1)
> | clf
> | surfl (peaks ())
> | xlabel ("X")
> | ylabel ("Y")
> | zlabel ("Z")
> | title ("surfl (peaks ())")
> | set (gcf, "paperunits", "inches")
> | set (gcf, "papersize", [6, 4.5])
> | set (gcf, "papertype", "<custom>")
> | set (gcf, "paperposition", [0, 0, 6, 4.5])
> | print (gcf, "-deps", "test_surfl.eps")
> | print (gcf, "-dpdf", "test_surfl.pdf")
> | print (gcf, "-dpng", "test_surfl.png")
> | print (gcf, "-dpng", "-r300", "test_surfl-300dpi.png")
>
> When I try these commands, the pdf version fails because my gnuplot
> (4.2.4, Debian testing) wasn't built with pdf support (why not?) and
> then gnuplot spews a lot of "invalid character" messages.  Maybe we
> need to detect whether a terminal is supported and then fail a bit
> more gracefully.  But don't worry about fixing that in this changeset.

We can ask gnuplot what terminals are supported and check that the one  
we want is there. That would be a rather simple feature to implement.

> Also, for the PNG terminal type, I get messages about Arial not being
> found.  I don't care whether the default is Arial or Helvetica, but if
> it still fails, why switch to Arial?  How can we make this just work?
> Again, this is probably something that you don't need to fix in this
> changeset, but I do think we need to fix it before 3.2.

At the moment, I don't know how to even get started with this. The  
gnuplot 4.3 & 4.2 manuals include the comment below.

PNG images are created using libgd, with optional support for TrueType  
and Adobe Type 1 fonts via
libfreetype. Version 1.8 or greater of libgd is required.

I assume you do have freetype installed and your libgd > 1.8?

> I see the tic labels for x and y axes in the plot placed on top of the
> axes lines.  Is that intended?  Do you also see that?

No that is not intended, but I don't yet have a solution for 3D. The  
problem is that gnuplot positions the tick-labels, axes-labels, and  
title according to the font-size of the font specified (or implied) by  
the "set terminal png ... font <name,size>" statement.

If the resolution of the plot is changed the font grows/shrinks. For  
bitmaps the text is anchored at its baseline. For postscript and pdf,  
it is anchored at its vertical center. Also, I'm not sure how  
horizontal alignment for bitmaps is implemented.

> | (3) Try running the demos for "gnuplot_label_offset" from the Octave
> | command line to see some examples of how the tick-labels, axes- 
> labels,
> | and title are positioned for several differnt situations. These  
> demos
> | are intended for evaluation puposes only, and should be removed  
> before
> | being committed.
>
> Does it cause any trouble to keep the demos?  If not, then I'd say
> keep them.
>
> | In addition, the gnuplot_label_offset function should
> | be incorporated into __go_draw_axes__.m.
>
> OK.
>
> | (1) The present status of Octave relies upon the user to properly
> | specify the axes "position" and "units" (normalized) properties, as
> | well as the figure properties; "position", "units" (pixels),
> | "papersize", "papertype", "paperposition", and  
> "paperuntis" (inches).
>
> I'm not sure I understand.  Are they no reasonable defaults that could
> be set?

The defaults are ok now. However, there are no listeners implemented  
yet to handle changes in "units" or "paperunits" (should these be made  
read-only for now?). Also due to a lack listeners, if the paper  
properties are changed, all must be changed in a consistent manner.

> | To produce expected results for objects with the fontname "*",
> | gnuplot_drawnow() will substitute the same default as used by  
> gnuplot
> | itself, or when there are no standard gnuplot defaults, will favor
> | Helvetica (for consistency with Matlab).
>
> Then why does your changeset use Arial?

Using png, Helvetica did not work for me, but Arial does.

> jwe