Opened 12 years ago

Closed 11 years ago

#10184 closed enhancement (fixed)

wxOSX: another patch for improved printing support

Reported by: lillo Owned by: csomor
Priority: normal Milestone:
Component: old wxOSX/Carbon port Version: stable-latest
Keywords: printing osx Cc:
Blocked By: Blocking:
Patch: yes



I've made additional modifications to the OSX printing support: now the quality setting in wxPrintData is respected, due to the fact we query the printer for supported resolutions and we choose a proper one based on the requested quality.
There was also a problem with PMPrinterGetOutputResolution() under 10.5; this failed with certain drivers if PMPrinterSetOutputResolution() wasn't called first (which wasn't the case); this caused the resolution to be set to a fake 300x300 dpi, which obviously was different from the real printer dpi... Later in the print code PMGetResolution() was called instead of PMPrinterGetOutputResolution(), so another dpi was returned. The result: printed paper looked correct, while preview was scaled 4x in my case (my printer was using 1200x1200 dpi).
Additionally, PMSetResolution() will not be available in 64 bit, so I added a code path that does not make use of it. It is suggested by Apple to use CGContextScaleCTM() to scale drawing according to the user needs instead of calling PMSetResolution()... The patch does this, but it required to modify all the results of PMGetAdjustedPageRect(), as these were not returning scaled rects (I had to scale them manually).

All in all, the patch solves some problems and should be 64 bit ready and fully backward compatible. I've tested only on 10.5 though so feedback is welcome.

Attachments (1)

wx_osx_printing.patch download (12.6 KB) - added by lillo 12 years ago.
The patch

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by lillo

The patch

comment:1 Changed 12 years ago by roebling

  • Status changed from new to confirmed

Thanks for providing the patch. It is a rather long and involved patch and I'd feel better if it solved a bug visible in a sample, most likely the printing sample. Is this the case on your system? If not, could you provide a patch to the sample that demonstrates the problem (apart from the API problem) and which then disappears with you patch?

comment:2 Changed 12 years ago by lillo

Hi Robert,

I understand your need, but providing a testcase showing a problem the patch solves isn't easy, for a variety of reasons.
As I reported above, the API misuse in current trunk only produces problems on certain printer drivers; for example, at work I have two printers installed, and while on one the print sample (samples/printing) showed a correctly scaled preview, on the other one showed an incorrectly scaled page. This is probably due to the API problem explained earlier (mixing new and deprecated calls)...

If you really want to test this thing, I'd suggest trying with different printers attached to your Mac using 10.5, if you can. I really can't help to show you the problem since it doesn't always show to me too (depends on attached printer).

comment:3 Changed 12 years ago by csomor

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


thanks for pointing out these things, I'll try to integrate things as much as possible, note however the usage of #ifdefs is not sufficient to make sure code degrades gracefully, code compiled against 10.5 sdk must run correctly under 10.4 (not under 10.3) on trunk as of now, you must also use weak link tests (eg if (PMPrinterGetOutputResolution !=NULL) ) to find out whether a function like PMPrinterGetOutputResolution is really available at runtime.

Also please indicate which Printer and Drivers gave you which problems, so that we can reproduce and test code paths, especially having a printer that doesn't implement output resolutions listing would be interesting, to really test the alternate code path there (some of the used functions might return kPMNotImplemented as well - at least according to the docs ..)



comment:4 Changed 12 years ago by lillo

I know about the weakrefs, I've only tested things under 10.5 though, and I'm sure there are places where I didn't test for functions availability... lazy programmer's habit, and that's why I pointed earlier that more tests and feedback on < 10.5 is welcome :-)
By the way, from what you say it seems that 10.3 isn't supported anymore in trunk, am I right in assuming so?

Anyway, glad you'll integrate the changes, here they really make a difference.

Ah, the culprit printer is a Brother HL-5250DL (default 10.5 CUPS driver).

Thank you.

comment:5 Changed 12 years ago by csomor


thanks for the info and yes, 10.3 is not supported anymore in trunk, otherwise I'd have to leave a lot of quickdraw stuff in there, and I had to clean up at least a little before going to support cocoa and 64 bit in the sources ...



comment:6 Changed 11 years ago by vadz

  • Milestone 2.9.0 deleted

Resetting 2.9.0 milestone as it's too late for it

comment:7 Changed 11 years ago by SC

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

(In [62749]) using 64bit APIs, closes #10184

Note: See TracTickets for help on using tickets.