Opened 12 years ago

Closed 12 years ago

#10343 closed defect (fixed)

Printing issues on Mac OSX 10.5.x

Reported by: jwh424 Owned by: csomor
Priority: normal Milestone: 2.9.0
Component: old wxOSX/Carbon port Version: 2.8.x
Keywords: Printing dcprint.cpp printmac.cpp Mac wxMax 2.8.9 Cc:
Blocked By: Blocking:
Patch: no

Description

The printing sample works on 10.4 without any issues; however, compiling and running on OSX 10.5, scaling becomes a problem. In some cases, I had to enter my own values to replace values coming from GetPageSizeMM, GetPageSizePixels, GetPPIPrinter and GetPPIScreen because they were either right or wrong. For example, 8.5 by 11 paper causes GetPageSizeMM to return 12mm by 15mm, which is not right and too small.

void PrintOutQuiltPrint::SetScale(wxDC * dc)
{
Get the logical pixels per inch of screen and printer
int ppiScreenX, ppiScreenY;
GetPPIScreen(&ppiScreenX, &ppiScreenY);
int ppiPrinterX, ppiPrinterY;
GetPPIPrinter(&ppiPrinterX, &ppiPrinterY);

This scales the DC so that the printout roughly represents the the screen
scaling. The text point size _should_ be the right size but in fact is
too small for some reason. This is a detail that will need to be
addressed at some point but can be fudged for the moment.
float scale = (float)((float)ppiPrinterX/(float)ppiScreenX);

Now we have to check in case our real page size is reduced (e.g. because
we're drawing to a print preview memory DC)
int pageWidth, pageHeight;
int w, h;
dc->GetSize(&w, &h);
GetPageSizePixels(&pageWidth, &pageHeight);

If printer pageWidth == current DC width, then this doesn't change. But w
might be the preview bitmap width, so scale down.
float overallScale = scale * (float)(w/(float)pageWidth);

dc->SetUserScale(overallScale, overallScale);
}

This piece of code produces an overallScale value of 13.333, which sets the dc to be 13 times larger.

The print preview seems to work ok. The attachment is what coming out of the printer. It looks nothing like the preview. Also when I print, the max number of pages is 9999 although there is only two.

I believe OSX 10.5 is breaking sometime dealing with scaling in wxMac 2.8.9. I've applied a patch from #10184 to wx version 2.9.x from the truck that should fix some resolution issues. The patch actually made the problem worst than before. Something is not right, and I confirmed with another person with OSX 10.4 that 10.5 may be causing a problem.

I have OSX 10.5.6 and Kodak ESP 9 printer.

Attachments (2)

wxWidgets Printing Demo.pdf download (37.6 KB) - added by jwh424 12 years ago.
Printing sample on OSX 10.5.6
4000 DPI.pdf download (20.6 KB) - added by jwh424 12 years ago.

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by jwh424

Printing sample on OSX 10.5.6

comment:1 Changed 12 years ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

the 9999 number has nothing to do with this problem, it is just for 'all pages'

the pdf when using HP and Xerox drivers shows no problem, I'm downloading the ESP 9 driver now and hope I can reproduce it without having the real hardware

comment:2 Changed 12 years ago by csomor

  • Priority changed from critical to normal

comment:3 Changed 12 years ago by jwh424

I'm using the Adobe 9.0 PDF printer which basically creates pdf using Arocbat Pro. This printer allows me to change the DPI resolution. When I've set the DPI to 72, everything prints fine. However when I change the DPI to 4000, the image is very large. I believe there is an issue when printing on high resolution printers like the kodak esp 9.

Changed 12 years ago by jwh424

comment:4 Changed 12 years ago by csomor

as I'm also getting up to 1200 dpi for my printers which in my tests printed fine, we have to establish a scenario to make sure I really perform the same steps as you,

  • to minimize the actions in the app itself, I set the desired printer as default in the system settings
  • I start up the printing sample
  • select Print from the menu
  • select PDF -> Save as PDF

I was using a Phaser 6250 with dpi set to 300 and an Epson Stylus 1400 with dpi set to 720, both produced identical PDFs

OS X 10.5.6, wx built using XCode projects against 10.5 SDK for minimum system 10.4 (which I start to think being the pivot element, what exact configure line are you using) ?

comment:5 Changed 12 years ago by csomor

ok got it, rebuilt for 10.5 minimum system, this makes the difference, I have two special cases in code for that, which eg in the Epson case don't give the currently selected DPI but perhaps the first DPI supported, I'll check out that, but for you as you've marked the bug as 'critical', either build for 10.4 minimum against 10.5 sdk, or plain 10.4, it will then also run under 10.5

comment:6 Changed 12 years ago by SC

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [57932]) removing Leopard only code that doesn't mix well with the existing Printing Manager, fixes #10343

Note: See TracTickets for help on using tickets.