Re: Issue with NSPrintInfo values being weird...
Re: Issue with NSPrintInfo values being weird...
- Subject: Re: Issue with NSPrintInfo values being weird...
- From: Mark Piccirelli <email@hidden>
- Date: Fri, 6 Sep 2002 20:34:02 -0700
Actually, that was a lousy answer from me, via DTS. I have a better
answer now though. From the Jaguar NSPrintInfo release notes at
<
http://developer.apple.com/techpubs/macosx/ReleaseNotes/AppKit.html>:
"It is important in many applications to be able to reliably determine
the maximum imageable area of a printed page. A new method has been
added to NSPrintInfo:
- (NSRect)imageablePageBounds;
Returns the imageable area of a sheet of paper specified by this
object, taking into account the current printer, paper size, and
orientation settings, but not scaling. "Imageable area" is the maximum
area that can possibly be marked on by the printer hardware, not the
area defined by the current margin settings. The rectangle is in a
coordinate space measured by points, with (0, 0) being the lower-left
corner of the oriented sheet and (paperWidth, paperHeight) being the
upper-right corner of the oriented sheet. The imageable bounds may
extend past the edges of the sheet when, for example, a printer driver
specifies it so that borderless printing can be done reliably."
So, there's no bug (anymore), only inconsistent usage of the word
"margins" in the NSPrintInfo API and the printing UI.
If you want to make your printed page images cover as much paper as the
hardware will support, send the NSPrintInfo -imageablePageBounds and
-paperSize messages, use the returned values to calculate margins, and
set the margins using the NSPrintInfo -set...Margin: methods. If your
app changes the display of something based on margins, you should
probably do this synchronization after every presentation of a Page
Setup panel, after creating an NSPrintInfo, and immediately after
opening documents, if your app has documents that contain archived
NSPrintInfo objects. If the margins have no effect except at printing
time, you can just fix them up right before creating NSPrintOperations.
(Stiphane, the bug you filed yesterday has been marked as a duplicate
of the one that Pierre-Olivier originally filed.)
(Pierre-Olivier, if you have reason to believe that the printing system
is being too pessimistic about the imageable area on your LaserWriter
630 with A4, please do file a separate bug. I myself don't know what
the real printing area of a 630 on A4 is supposed to be.)
-- Mark
On Thursday, September 5, 2002, at 10:40 AM, Scout wrote:
InstaPix is returning YES, and using the values returned by
NSPrintInfo. Thus, when Apple fixes this bug, InstaPix will
automatically print using the full available printing area. Then I'll
happily deal with adding an application defined margin.
I've noted that Sherlock.app has the same print margins bug (nice to
see Apple ship Cocoa apps instead of Carbon).
This is a horrible bug for the recommended and latest object oriented
interface to the seminal desk top publishing platform.
The rest of the printing support from Cocoa is top notch, nothing
better on the planet.
(that's a lousy answer from DTS)
cheers
On Thursday, September 5, 2002, at 09:30 AM, Pierre-Olivier Latour
wrote:
On Thursday, September 5, 2002, at 05:40 PM, Scout wrote:
The one inch margin issue does continue, and filing the bug again
would
not be a bad thing.
Already done a few months ago. Here's the official answer from
email@hidden:
********* MAIL #1
The "margins" that appear in the Page Setup dialog aren't margins,
at least
not in the typical application sense. They don't have much to do
with the
margin you can set in a Microsoft Office app, for instance. They're
really
the bounds of the imageable area of the paper, usually defined by the
printing hardware.
Then if these margins specify the printing area of the paper, they are
totally incorrect in my case. I'm using an LaserWriter 630 with A4
paper.
Printing area is only a few millimeters less than the A4 surface,
definitely
not around 0.25 inch on each side.
Should I report a bug for it?
So, they don't have much to do with the margins that you get out of
an
NSPrinInfo.
Thank you for the details. However, since I could not find this
information
in the docs, would you mind telling me exactly what the margins
returned by
NSPrintInfo mean?
<GMT15-Jul-2002 12:44:08GMT> Pierre-Olivier Latour:
* SUMMARY
When going into the Page setup dialog and displaying the summary
panel, you
can see that the margins for A4 paper are set as follow:
Left = 0.25''
Top = 0.25''
Bottom = 0.57''
Right = 0.25''
However, when fetching this info the Cocoa object [NSPrintInfo
sharedPrintInfo] and the methods leftMargin, rightMargin and so on,
you get
the following:
Left = 1.00''
Top = 1.25''
Bottom = 1.25''
Right = 1.00''
*********** MAIL #2
Thank you for the details. However, since I could not find this
information
in the docs, would you mind telling me exactly what the margins
returned by
NSPrintInfo mean?"
Margins in the NSPrintInfo sense are the amounts of blank space that
should
be left on the left, top, right, or bottom edge of each page when
automatically paginating a view. They're typically larger than the
blank
spaces that are dictated by hardware limitations. Margins in an
NSPrintInfo
are used during automatic pagination unless the printing view returns
YES
when sent a -knowsPageRange: method (see the docs for a description
of the
-knowsPageRange: business). See the TextEdit and Sketch sample
projects for
some manipulations of NSPrintInfo margins. There's no standard Cocoa
UI for
letting users set the margins in a document's NSPrintInfo.
***********
Hope this helps :)
_____________________________________________________________
Pierre-Olivier Latour email@hidden
Lausanne, Switzerland http://www.pol-online.net
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.