MATLAB Central Newsreader - problems printing to file

problems printing to file

ross — Sun, 12 Apr 2009 14:21:30 -0400

Dear folks

What I want to do is very straighforward - to transfer the plotted screen
figures exactly as they appear on the screen to graphics files with the same
pixel dimensions and the same colour depth as the screen figure, under program
control. Lossless compression is desirable, but not obligatory.

In R2008b, using the PRINT command, the -dbitmap driver is the only one that
creates the correct sized file image, but it is not acceptable for shaded
figures because it cuts the colour depth from 24bit to 8bit.
The -dbmp, -dpng and -dtiff drivers retain 24bit colour but are completely
useless because they save only a fraction of the screen figure (a rectangle
based on the lower lefthand corner), and the size of this portion is not
altered by any of the dpi settings.
Fiddling with all the options that are allowable in the PRINT command doesn't
seem to fix any of these problems.

Interactive saving to file via the Figure menu bar DOES work. Furthermore, if
I change the File / Export Setup / Rendering / Resolution setting from 'auto'
to 'screen', then further exporting of the same figure in m-code (PRINT
command) now works correctly. It continues to work correctly even if the
setting is changed back to 'auto' ! However this is specific to each figure,
and means that prior manual intervention is necessary for every figure. I
couldn't find any option for the PRINT command or in the various startup files
that has the same effect. The '-r0' option certainly doesn't.

My programs usually generate multiple plots, from 5 to 30 at a time, so I need
the figures to be saved under program control. I don't see everyone else
complaining about this: so if it's something I'm doing wrong, what the hell
is it?
Is there a command which can be used in m-files which has the same effect as
setting Resolution to 'screen' in the Export Setup?

Thanks
Ross

Re: problems printing to file

Jiro Doke — Sun, 12 Apr 2009 19:56:01 -0400

Ross <ross@nospam.com> wrote in message <49e1f8e8@news.mel.dft.com.au>...
> Dear folks
>
> What I want to do is very straighforward - to transfer the plotted screen
> figures exactly as they appear on the screen to graphics files with the same
> pixel dimensions and the same colour depth as the screen figure, under program
> control. Lossless compression is desirable, but not obligatory.
>
> In R2008b, using the PRINT command, the -dbitmap driver is the only one that
> creates the correct sized file image, but it is not acceptable for shaded
> figures because it cuts the colour depth from 24bit to 8bit.
> The -dbmp, -dpng and -dtiff drivers retain 24bit colour but are completely
> useless because they save only a fraction of the screen figure (a rectangle
> based on the lower lefthand corner), and the size of this portion is not
> altered by any of the dpi settings.
> Fiddling with all the options that are allowable in the PRINT command doesn't
> seem to fix any of these problems.
>
> Interactive saving to file via the Figure menu bar DOES work. Furthermore, if
> I change the File / Export Setup / Rendering / Resolution setting from 'auto'
> to 'screen', then further exporting of the same figure in m-code (PRINT
> command) now works correctly. It continues to work correctly even if the
> setting is changed back to 'auto' ! However this is specific to each figure,
> and means that prior manual intervention is necessary for every figure. I
> couldn't find any option for the PRINT command or in the various startup files
> that has the same effect. The '-r0' option certainly doesn't.
>
> My programs usually generate multiple plots, from 5 to 30 at a time, so I need
> the figures to be saved under program control. I don't see everyone else
> complaining about this: so if it's something I'm doing wrong, what the hell
> is it?
> Is there a command which can be used in m-files which has the same effect as
> setting Resolution to 'screen' in the Export Setup?
>
> Thanks
> Ross

Ross,

To programmatically set the plot to save as you see on the screen, set the PaperPositionMode of the figure to "auto".

>> surf(peaks)
>> set(gcf,'PaperPositionMode','auto')
>> print -dpng -r0 peaks.png

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/figure_props.html#PaperPositionMode

Re: problems printing to file

ross — Mon, 13 Apr 2009 06:42:31 -0400

"Jiro Doke" <jiro.doke@mathworks.com> wrote:

>To programmatically set the plot to save as you see on the screen, set the
>PaperPositionMode of the figure to "auto".
> ......
>>> set(gcf,'PaperPositionMode','auto')

Thanks Jiro.

I should have guessed - it's this old problem of printer settings and concepts
interfering where they are not relevant.
Permit me a small rant - see if you agree with the following.

It's high time that printer specific concepts such as dpi and paper position
should be completely removed from the process of saving figures to graphics
files. It's insane and always has been. I've been programming since the early
70s and these concepts have confusing people ever since then. How many
thousands of times have you seen charts spewing out of the printer with the
wrong size because someone got confused between the file resolution, the dpi
and the printer settings? Especially now, when the need for direct output to a
printer is becoming rarer. Programmers in general find the concept of
specified pixel dimensions for the screen, and for the bitmapped graphics
files, a very easy one to master. One just interpolates to make one fit the
other if necessary. Dpi was a particularly iniquitous concept because it
introduced complexity where none was needed. At bottom, a bitmapped graphics
file has a certain information density, and the printer in any given mode has
another. A single ratio is logically enough. In printer-oriented contexts,
however, one was often drowning in ratios - dpi's for the file and printer, for
a start, plus other settings - and in the end fudge factors often had to be
applied before the output was what you'd expected. Historically, it's been a
shambles. Vectorised graphics have their own language, but again it's far less
confusing if file creation and printing from file are kept as separate
activities. Many academics and researchers want to save their figures to a file
in a suitable format, then interpolate, crop, overlay, edit, insert into
journal articles or presentations, email to friends or publishers, etc. ALL of
this is done electronically, and printing simply doesn't come in to it. All
printer-specific settings, eg, margins, dpi, paper size and position, should
be relegated to a special set of commands that are completely separate from
those used for creating graphics files. If we modularised these activities, and
the clarity and robustness of the command structure would improve considerably.

ross

Re: problems printing to file

Christophe Charbu — Tue, 25 Aug 2009 12:52:01 -0400

Dear ross,
Thank you for pointing out this problem.
Do you find a solution to fix the figure size correctly?

Thank you in advance.

Christophe

ross <ross@nospam.com> wrote in message <49e2deda@news.mel.dft.com.au>...
> "Jiro Doke" <jiro.doke@mathworks.com> wrote:
>
> >To programmatically set the plot to save as you see on the screen, set the
> >PaperPositionMode of the figure to "auto".
> > ......
> >>> set(gcf,'PaperPositionMode','auto')
>
> Thanks Jiro.
>
> I should have guessed - it's this old problem of printer settings and concepts
> interfering where they are not relevant.
> Permit me a small rant - see if you agree with the following.
>
> It's high time that printer specific concepts such as dpi and paper position
> should be completely removed from the process of saving figures to graphics
> files. It's insane and always has been. I've been programming since the early
> 70s and these concepts have confusing people ever since then. How many
> thousands of times have you seen charts spewing out of the printer with the
> wrong size because someone got confused between the file resolution, the dpi
> and the printer settings? Especially now, when the need for direct output to a
> printer is becoming rarer. Programmers in general find the concept of
> specified pixel dimensions for the screen, and for the bitmapped graphics
> files, a very easy one to master. One just interpolates to make one fit the
> other if necessary. Dpi was a particularly iniquitous concept because it
> introduced complexity where none was needed. At bottom, a bitmapped graphics
> file has a certain information density, and the printer in any given mode has
> another. A single ratio is logically enough. In printer-oriented contexts,
> however, one was often drowning in ratios - dpi's for the file and printer, for
> a start, plus other settings - and in the end fudge factors often had to be
> applied before the output was what you'd expected. Historically, it's been a
> shambles. Vectorised graphics have their own language, but again it's far less
> confusing if file creation and printing from file are kept as separate
> activities. Many academics and researchers want to save their figures to a file
> in a suitable format, then interpolate, crop, overlay, edit, insert into
> journal articles or presentations, email to friends or publishers, etc. ALL of
> this is done electronically, and printing simply doesn't come in to it. All
> printer-specific settings, eg, margins, dpi, paper size and position, should
> be relegated to a special set of commands that are completely separate from
> those used for creating graphics files. If we modularised these activities, and
> the clarity and robustness of the command structure would improve considerably.
>
> ross