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
_______________________________________________

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

Reply via email to