[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[changeset] print.m (matlab compatibility)

From: Ben Abbott
Subject: [changeset] print.m (matlab compatibility)
Date: Mon, 09 Mar 2009 23:03:35 +0800

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)
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 viewing the eps file use an app like ghostview so that the image displaed reflects the extents of the bounding box. For example, from the shell ...

        $ gv test_surfl.eps

Or form Octave, via system()

        > system ("gv test_surfl.eps")

If you have a window's box, you can try gsview (after a download and install).

In these 3D examples, the placment of the axes-labels and tick-labels is not aesthetically pleasing. I'm not sure how to properly handle this, but hope look at it in the future.

(2) ex: contour(peaks) printed on usletter in ps, pdf, png (default resolution), and png at 300dpi.

set (0, "defaultaxesfontsize", 10)
set (0, "defaultetxtfontsize", 10)
set (0, "defaultaxesfontname", "*")
set (0, "defaultetxtfontname", "*")
figure (1)
contour (peaks ())
xlabel ("xlabel")
ylabel ("xlabel")
title ("title")
set (gcf, "paperunits", "inches")
set (gcf, "papersize", [8.5, 11])
set (gcf, "papertype", "usletter")
set (gcf, "paperposition", [0.25, 2.5, 8, 6])
print (gcf, "-dps", "usletter.ps")
print (gcf, "-dpdf", "usletter.pdf")
print (gcf, "-dpng", "usletter.png")
print (gcf, "-dpng", "-r300", "usletter-300dpi.png")

When viewing the postscript output, use ghostview or an equivalent so that image diplayed reflects the extents of the page, and not the bounding box (or you can just print it).

For this 2D example, Octave is making some adjustments to the positiong of the axes-labels, tick-labels, and the title. The result should look similar to Matlab's default behavior. The result is intended to be consistent across miltiple gnuplot terminals. Aqua term is a bit of an outlier, in the negative direction. However, the Aquaterm result wasn't too good befor.

(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. In addition, the gnuplot_label_offset function should be incorporated into __go_draw_axes__.m.

        demo gnuplot_label_offset

Some qualifiers:

(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).

(2) If the "position" property of the axes-labels and/or title are specified it is ignored. These await low level backend support for calculating the text extents, which will merit a significant rewrite of the gnuplot backend.

Some comments regarding this changeset:

A trivial bug fix is buried in this changeset. "xaxisposition" should be "yaxisposition" in __go_draw_axes__:do_tics

-1471   elseif (strcmpi (obj.xaxislocation, "zero"))
+1471   elseif (strcmpi (obj.yaxislocation, "zero"))
1472 do_tics_1 (obj.ytickmode, obj.ytick, obj.yminortick, obj.yticklabelmode, 1473 obj.yticklabel, obj.ycolor, "y", plot_stream, ymirror, mono, 1474 "axis", obj.tickdir, ticklength, fontname, fontsize,
 1475                obj.interpreter);

This implementation adds three new figure properties to allow print(), and gnuplot_drawnow(), to communicate with __go_draw_axes__().

        __gnuplot_default_font_size__ = terminal dependent default fontsize.

        __gnuplot_printing_bitmap__ = true when printing bitmaps.

        __pixels_per_inch__ = the dpi of the printed output.

These properties hold necessary information while printing, otherwise default values. These properties are only needed when printing, and I'd prefer to have them hidden from the user. I'd like to be able to delete them after printing. Is there presently a way to do that?

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).

I've tested this with jwe's changeset that sets the defaultaxesfontname and defaulttextfontname to "*", and all work as expected for me.


Attachment: changeset-print.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]