[changeset] print.m (matlab compatibility)

[Ben Abbott]

On Mar 10, 2009, at 7:58 AM, Ben Abbott wrote:

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

John,

Does the attached find a font that works with the png terminal on our  
system?

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset-print.patch
Type: application/octet-stream
Size: 39753 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090310/bafd6bd5/attachment-0001.obj 
-------------- next part --------------