Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: problems printing to file
Date: Tue, 25 Aug 2009 12:52:01 +0000 (UTC)
Organization: The MathWorks, Inc.
Lines: 52
Message-ID: <h70mph$ll7$1@fred.mathworks.com>
References: <49e1f8e8@news.mel.dft.com.au> <grth0h$ccv$1@fred.mathworks.com> <49e2deda@news.mel.dft.com.au>
Reply-To: <HIDDEN>
NNTP-Posting-Host: webapp-02-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1251204721 22183 172.30.248.37 (25 Aug 2009 12:52:01 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Tue, 25 Aug 2009 12:52:01 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 1934302
Xref: news.mathworks.com comp.soft-sys.matlab:565781


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