[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)
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 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)
clf
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.
Ben
changeset-print.patch
Description: Binary data
- [changeset] print.m (matlab compatibility),
Ben Abbott <=
- [changeset] print.m (matlab compatibility), John W. Eaton, 2009/03/09
- [changeset] print.m (matlab compatibility), John W. Eaton, 2009/03/09
- Re: [changeset] print.m (matlab compatibility), Ben Abbott, 2009/03/09
- Re: [changeset] print.m (matlab compatibility), Ben Abbott, 2009/03/09
- Re: [changeset] print.m (matlab compatibility), Ben Abbott, 2009/03/09
- Re: [changeset] print.m (matlab compatibility), John W. Eaton, 2009/03/10
- Re: [changeset] print.m (matlab compatibility), Ben Abbott, 2009/03/10
- Re: [changeset] print.m (matlab compatibility), Shai Ayal, 2009/03/10
- Re: [changeset] print.m (matlab compatibility), Ben Abbott, 2009/03/10
- Re: [changeset] print.m (matlab compatibility), Shai Ayal, 2009/03/10