Path: news.mathworks.com!newsfeed-00.mathworks.com!newsfeed2.dallas1.level3.net!news.level3.com!postnews.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!novia!news1.optus.net.au!optus!news.optus.net.au!53ab2750!not-for-mail
From: ross <ross@nospam.com>
Subject: Re: problems printing to file
Newsgroups: comp.soft-sys.matlab
References: <49e1f8e8@news.mel.dft.com.au> <grth0h$ccv$1@fred.mathworks.com>
X-Original-NNTP-Posting-Host: 202.61.162.14
Message-ID: <49e2deda@news.mel.dft.com.au>
X-Original-Trace: 13 Apr 2009 16:42:34 +1100, 202.61.162.14
Lines: 43
Date: Mon, 13 Apr 2009 06:42:31 GMT
NNTP-Posting-Host: 203.123.72.37
X-Complaints-To: luke.johnson@team.eftel.com
X-Trace: news.optus.net.au 1239604951 203.123.72.37 (Mon, 13 Apr 2009 16:42:31 EST)
NNTP-Posting-Date: Mon, 13 Apr 2009 16:42:31 EST
Organization: EfTel - reports relating to abuse should be sent to luke.johnson@team.eftel.com
Xref: news.mathworks.com comp.soft-sys.matlab:532248


"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