Bug 276549 - [printing] top row of pixels cut off
Summary: [printing] top row of pixels cut off
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.5   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-15 14:52 EDT by Grant Gayed CLA
Modified: 2021-11-12 11:39 EST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Grant Gayed CLA 2009-05-15 14:52:39 EDT
3.5RC1 test candidate build 20090514-2000

- run Snippet132
  -> note that the top of the box drawn around the Hello World! text is missing
- this printed fine with carbon from the same machine
Comment 1 Felipe Heidrich CLA 2009-05-19 11:06:55 EDT
CM to investigate.
Comment 2 Carolyn MacLeod CLA 2009-05-19 16:16:34 EDT
This is because the Cocoa call:
	NSRect bounds = printInfo.imageablePageBounds();

is returning a larger y-value than the Carbon call:
	OS.PMGetAdjustedPaperRect(pageFormat, paperRect);

On Carbon the AdjustedPaperRect.top is -18, and on Cocoa the imageablePageBounds.y is 40 (for the 2 printers that I am trying this on).

The Carbon values are negative because they mean "where is the edge of the paper with respect to the printable area", and the Cocoa values are positive because they mean "where is the edge of the printable area with respect to the edge of the paper". However they should have the same absolute value. The .left and .x have the same value (-18 and 18).

So the reason this snippet is failing is that it is offsetting printing 1/2 inch below the top edge of the paper, but at 72 DPI, 1/2 inch is 36 dots and that is 4 pixels above 40, so the 4 pixels are being clipped.

The snippet is not very robust - it should be rewritten to draw at "1/2 inch below the top edge of the paper or the top of the drawable area, whichever is greater".

However, I do not know why there is a difference between the value returned by the different Carbon and Cocoa natives. Scaling does not seem to be a factor, because the scale factor is 1.

I will only release the snippet changes for now.
Comment 3 Eclipse Webmaster CLA 2019-09-06 15:38:07 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.