Gerry, Seems if you knew the printer's resolution you can determine the pixel within XML Horz/Vert to use. As a first step, try to find the printer's resolution. based on this you can then determine the expected size you want to print, a 5" by 7" or a 6" by 4" or 8" by 10". Horizontal is inches_wanted is XML Horz resolution divided by printer's Resolution. example: say you have a pixel image of 2400 by 2400 and using 300 ppi (or say dpi), then 2400/300 is 8", assuming this is horizontal. For vertical change 2400 to 3000. Also, the Print dialog might allow the user to pick/choose the Width in inches and to center, might be something to consider given that not all printer drivers are alike.
so, it might all come down to poking the printer's driver and ask about Resolution it supports (again, there is no issues writing to the screen). how about trying to find the printer's supported resolution, then determine the missing XML Horz value say you wanted 8" then 8 times printer's resolution is the new XML Horz resolution wanted. so how about some calls to like: 1. countP - variable contains the number of resolutions that are supported for the specified printer. with this setting found you should be able to compute the expected Hoz Inches given that you can control the XML Hoz Res, etc. PMPrinterGetPrinterResolutionCount2. Set Printer Output Resolution to 300, you might have to have the printer dialogue box pop up so the user can control. it says that: "this function is rarely used. Most applications do not set the output resolution but instead use the setting supplied by the user in the Print dialog."PMPrinterSetOutputResolutionbest of luck, Tom On Mon, Feb 7, 2011 at 11:34 PM, Gerry Beggs <gbeg...@mts.net> wrote: > Hi. Thanks for the clarification. > I am aware of the difference and perhaps I was a little careless with my > wording. > > The XML in the PageFormat settings doesn't mention dpi or ppi. It mentions > horizontal and vertical "resolution". > > specifically: > <key>com.apple.print.PageFormat.PMHorizontalRes</key> > <real>2400</real> > and > <key>com.apple.print.PageFormat.PMVerticalRes</key> > <real>2400</real> > > But it is my understanding that when printing in Cocoa, coordinates are > assumed to be in points (72 integer coordinates per inch) unless the > CGContext transformation is modified. > That is how I draw to the screen, and it is appearing the same when the > print preview is being displayed in the print dialog. > > > I am calling PMSetResolution to set the resolution to 72 points per inch. > This function is deprecated with a note saying, to scale the CGContext > transformation to change the print resolution instead. > Implying that the printing coordinates should start off at 72 points per > inch. > > > I also tried just filling the entire page with a solid color using the > rectangle passed to drawRect: (and nothing else). > That still only filled the small rectangle in the lower-left corner (until > I called PMSetResolution to set it to 72 points per inch). > > > On 2011-02-07, at 8:40 PM, Tom dineen wrote: > > Gery > some minor pointa might be related if you can take a read here... > > is dpi same as pixels per inch (ppi). > a fact using Photoshop or printing is to use 200 or 300 ppi (the density or > spatial resolution). screens are fine with 100 ppi an iPhone4 creates a > photo with 72 ppi. but to print this would be a small photo on a printer. > > how big an image prints depends on resolution or ppi of the image. > > not sure how xml is transposed into a print image but sounds similar to > printing an image... > > maybe this is a bug but all depends on printing with a higher ppi vs > viewing on screen with a lower ppi - which is as expected based on density > of pixels. > > > Sent on iPhone ( check spell Off, Auto Correction Off ) > > Tom Dineen > > > On Feb 7, 2011, at 8:24 PM, Gerry Beggs <gbeg...@mts.net> wrote: > > Thanks Raleigh. > > I discovered a work-around. But there does appear to be a bug. > > > This was difficult for me to test because I wasn't able to reproduce it > (from a new document) on my machine. But I received a document created by a > user on their machine which I was able to use to reproduce the problem. This > problem must depend on the printer driver being used. > > The document file contains the PMPageFormat data saved as XML > representation using PMPageFormatCreateDataRepresentation(...) > > > > On my machine (and most users' machines) the print resolution saved in the > XML is set to 72 dpi. > > But in the sample document I received, the print resolution was set to 2400 > dpi. > > > When drawing the page content, the CGContext transform was set correctly > when rendering the print preview, but when rendering the actual printed > page, the CGContext's transform scale was changed to 3% (= 72/2400) (If I > tried to change the scaling back to 100%, the clipping rectangle still > limited me to drawing in the small rectangle in the corner) > > > > Long story short, I fixed the problem by calling the deprecated function > PMSetResolution on the PMPageFormat to set it to 72 dpi before printing. > > I use a preprocessor condition preventing this line from compiling as > 64-bit. > > > > If there's a good explanation of why this happened, I'd like to know. > > But the fact that the print preview didn't render the same as the actual > printout tells me that it might be a bug. > > > > On 2011-02-07, at 11:11 AM, Raleigh Ledet wrote: > > > Gerry, > > > File a radar. Include the file or a sample project or whatever you can to > help us duplicate. If this is a Cocoa bug, then you should be able to > duplicate with a small sample app pretty quickly. > > > -raleigh > > > On Jan 18, 2011, at 5:42 PM, Gerry Beggs wrote: > > > Just to follow-up (and clarify) my own problem: > > > I have implemented NSDocument's printOperationWithSettings: method to kick > off the printing process when the user selects Print from the File menu. > > > I am using the same NSView drawRect: method to display on-screen as when > printing. > > The Print Preview in the Print Dialog always appears correct. > > However, the final print output is appearing scaled down, either when > printing to paper, or to PDF. > > > When the problem presents itself, the transformation of the CGContext is > the same when drawing the print preview as when drawing the actual output. > That is, it is scaled down, which explains why the output is small. > > When the problem doesn't present itself, the transformation is the identity > transformation when drawing the actual output. > > > > I've discovered that if I run my application as a 64-bit executable, the > problem goes away. > > When running under 32-bit, the problem is consistent. > > > Thanks for any help. > > > On 2011-01-16, at 1:24 AM, Gerry Beggs wrote: > > > I've been having a problem with my application sometimes (but not always) > printing the full page, but it appears VERY small in the lower-left corner > of the page. > > > I was having trouble reproducing it, but finally received a sample document > from one of my users that let me reproduce it. > > Still, sometimes it prints correctly filling the page, other times, it > prints scaled down in the lower-left corner of the page. > > > I am using NSPrintOperation from an NSDocument to handle the printing > operations. > > > When trying to debug this issue, I examined the transformation from my > view's drawRect method using CGContextGetCTM. > > I discovered something interesting: > > - When the printout appears scaled down, the transformation structure is > the same as it is when the print preview image is rendered. > > - When the printout appears full-sized, the transformation structure is the > identity matrix (ie. scale = 100%) > > > > Since the scale of the CGContext is the same when rendering the print > preview as it is when rendering the full-sized page, this explains why my > printouts are appearing very small in my output. > > > Values 'a' and 'd' in the CGAffineTransformation structure indicate the > scaling factor and for the print preview, it makes sense that it is scaled > down for the print preview. But somehow, the transformation is not being set > back to 100% scaling for the actual printing. > > > I've looked for unbalanced CGContextSaveGState/CGContextRestoreGState > calls, but they are all balanced. > > > I've spent too much time trying to debug this. If anyone can give any ideas > why my printouts are appearing scaled down, I would appreciate any help. > > Thanks. > > > -- > > gbeg...@gmail.com http://www.GerrysCuppaTea.org/ > > > _______________________________________________ > > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > > Please do not post admin requests or moderator comments to the list. > > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/cocoa-dev/gbeggs1%40mts.net > > > This email sent to gbeg...@mts.net > > > > -- > > gbeg...@gmail.com http://www.GerrysCuppaTea.org/ > > > _______________________________________________ > > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > > Please do not post admin requests or moderator comments to the list. > > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/cocoa-dev/ledet%40apple.com > > > This email sent to le...@apple.com > > > > > -- > > gbeg...@gmail.com http://www.GerrysCuppaTea.org/ > > > _______________________________________________ > > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > > Please do not post admin requests or moderator comments to the list. > > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/cocoa-dev/dineen5214%40gmail.com > > > This email sent to dineen5...@gmail.com > > > > -- > gbeg...@gmail.com http://www.GerrysCuppaTea.org/ > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
