[Octave-bug-tracker] [bug #44187] Bugs and modifications in print() with gnuplot graphics toolkit

[ederag]

Follow-up Comment #44, bug #44187 (project octave):

>From a pristine octave clone, some hunks are rejected, indeed. It looks like I
missed a change in __ghostscript__.m that happened 3 weeks ago. 
I'll look into that.

Meanwhile, I tried to fix some margins (paperposition) issues. 
Now I think that using papersize not only for paper printing, but also for
file printing would be much more consistent.
Paperposition should set the frame of the figure (the equivalent of the figure
border on screen) _inside_ the printout.

Matlab treats differently image formats and pdf formats.
http://fr.mathworks.com/help/matlab/ref/figure-properties.html#prop_PaperPosition
This is kind of weird, since pdf format could be either intended to have a
margin (e.g. printing a full a4 page), or not (e.g. a figure to be included in
latex). In the latter case, the sensible behaviour would be: no difference in
size/positions between png and pdf.

Matlab implementation is full of bugs/strange behaviours. See for instance
http://www.mathworks.com/matlabcentral/answers/218286-export_fig-paperposition-not-considered-when-exporting-to-pdf#answer_180198
http://www.mathworks.com/matlabcentral/answers/130735-font-size-and-figure-size-when-printing-figure-to-eps
http://www.mathworks.com/matlabcentral/answers/155249-printing-a-figure-with-latex-annonations-and-readable-linewidths-to-disk
So they also have problems to create a clean implementation, with such a weird
intended behaviour.

Most of the times recommendation are either to use of export_fig, e.g.
http://matlab.wikia.com/wiki/FAQ#How_do_I_save_my_figure.2C_axes.2C_or_image.3F_I.27m_having_trouble_with_the_built_in_MATLAB_functions
or to _both_ set papersize and paperposition, e.g.
http://stackoverflow.com/questions/11261823/export-matlab-figure-as-png
http://stackoverflow.com/a/7576598/3565696
https://dgleich.github.io/hq-matlab-figs/

My conclusion: there are so many problems in their approach that we should not
follow Matlab there.

We should use papersize to control the overall size of any printout (whatever
the format).
The recommended way to select the printout size to [5", 3"] for inclusion in
another software would be:
papersize = [5, 3];
set(gcf, "papersize", papersize)
set(gcf, "paperposition", [0 0 papersize])
To shorten things, we could define a new "paperpositionmode": "full", which
triggers a change of paperposition to [0 0 papersize] whenever papersize is
changed.

We could also have a "screen" papertype, that would set
"papersize" to the figure physical size on screen.
This would be a sensible replacement for the paperpositionmode "auto" of
matlab.

Please note that even with this big change, 
people setting both papersize and paperposition
won't see any difference between matlab and octave.

I'll be able to work on that in the last weeks of this year,
but please give me a go/no go signal.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44187>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/