octave-maintainers
[Top][All Lists]
Advanced

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

RE: print() and -S option to specify size (revisited)


From: John W. Eaton
Subject: RE: print() and -S option to specify size (revisited)
Date: Wed, 31 Oct 2007 12:55:15 -0400

--text follows this line--
On 30-Oct-2007, Peter A. Gustafson wrote:

| It seems that a size option has been added to the print command.  The
| changelog entry was:
| 
| 2007-10-06  Francesco Potorti`  <address@hidden>
|         * plot/print.m: Handle svg output type.  Accept new -S option to
|         specify size for PNG and SVG output types.
| 
| and the discussion was here in sources:
| http://www.cae.wisc.edu/pipermail/octave-sources/2007-October/000077.html
| 
| I'm not on the sources list, so I'm sorry for the late entry here.
| There had been prior discussion about -S for size, which had been turned
| away due to compatibility issues.
| http://www.cae.wisc.edu/pipermail/octave-maintainers/2007-August/003637.html
| 
| Can we now assume that -S is acceptable?  And have we settled on
| "-S640,480" vs "-S640x480".  Or perhaps this is matlab compatible for
| the specific terminal?
| 
| If acceptable, this should be expanded for other terminals (latex,
| pslatex, etc).  If not, should it be curtailed until a compatible method
| is established?
| 
| I think this is a fairly important issue, as plotting is a critical
| feature and desirable hardcopy rather essential.  I don't have a strong
| opinion as to whether compatibility is important, however a clear
| direction on the matter is important.  I assume we want to avoid
| establishing a backwards compatibility issue for when the final
| direction is established.

On 31-Oct-2007, Schirmacher, Rolf wrote:

| I would propose to be VERY careful here.
| 
| As far as I know, Matlab has a "-s" option, which is used for specifying a
| simulink block diagram to print. So, choosing the same character for a size
| option, even if it is uppercase, is obviously not a good idea as it is
| likely to cause confusion.
| 
| The second argument I have is that Matlab follows a totally different
| approach. On the one side, you can specify the papersize of a figure (which
| is a figure property) and on the other side you can specify the resolution
| of a printer. The concept of a size in terms of pixel does not at all occur
| in Matlab (not even with the bitmap file formats and print). 
| 
| Nevertheless, if we have a method to communicate the size of a plot to print
| to gnuplot (in pixel), implementing the concept of papersize as a figure
| property plus a printer resolution and then calculating the actual plot size
| (in pixel) for the graphics backend seems to be a viable approach.

I'd consider patches to implement compatible plot size things (after
3.0).

We also have to be careful here for another reason.  It is possible we
will drop gnuplot as the default plotting engine for 3.1 or 3.2, so
solutions that are tightly coupled with gnuplot may end up being
somewhat wasted effort.

I'm not sure why I accepted the patch to add -S.  Clearly I didn't
remember the previous discussion.  Perhaps it should be removed.

jwe


reply via email to

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