realbasic-nug
[Top] [All Lists]

Re: Printing high resolution - Carbon bugs

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: Printing high resolution - Carbon bugs
From: Andy Dent <dent at oofile dot com dot au>
Date: Tue, 9 Nov 2004 08:41:19 +0800
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <p06002004bdb44981f5ef at [203 dot 34 dot 30 dot 22]> <6 dot 1 dot 0 dot 6 dot 2 dot 20041107193311 dot 063aca00 at mail1 dot netreach dot net> <p06002001bdb48a0f1758 at [203 dot 34 dot 30 dot 17]> <6 dot 1 dot 0 dot 6 dot 2 dot 20041107213349 dot 07339ec0 at mail1 dot netreach dot net> <p06002000bdb4b4d30b5a at [203 dot 34 dot 30 dot 12]> <7AC7C639-31CC-11D9-A876-0003931D8DCC at componentx dot com>
Brad Hutching wrote
I still accept full blame for this if you want full control over your printing.

blame (and thanks) cheerfully given :-)


The downsides are (1) slow, low-memory network printers

in the space I'm working, a LOT of the user printers are non-PS devices like the Epson Stylus. Rasterisation at the computer is ineveitable especially for Windows.

and now (2) a problem with REALbasic passing printer resolution through.

uhh, did you read the whole thread? This isn't an RB problem - it's a LONG-term Carbon bug. eg: <http://www.macintouch.com/mosxreader10.2pt51.html>

PMPrinterGetPrinterResolutionCount always returns 1

The Apple attitude is reported as "hey, you have resolution-independent printing, why should you care?"

Most discussion of these problems is not visible in Google, search the "printing" or "carbon-dev" mailing lists at <http://search.lists.apple.com/>.

There does, however, seem to be an RB limit in that RB doesn't allow us to define the resolution we want the printer Graphics allocated at and so we're stuck (with RB printing) at the lower resolution. I haven't logged a bug because I'm not sure what to suggest as an alternative.

Has anyone filed a feature request to be able to access the raw printer data (XML, I imagine)?

There is already the PageSetup.PrinterSetupString which is XML but doesn't contain any list of extra resolutions, see tags such as com.apple.print.PageFormat.PMVerticalRes etc. I don't expect this to help as it's the same Carbon Session API which Apple seem disinclined to fix.

I spent a large portion of my weekend investigating this in the hope of being able to fling a chunk of working code at RS, or write my own plugin, either Carbon or Cocoa.

<http://developer.apple.com/documentation/Cocoa/Conceptual/Printing/Tasks/CreatingPrinters.html> is the most relevant documentation for parsing PPD's.

One problem is that there's not actually a standard way in the PPD (*if* one exists) to describe a range of resolutions. The (non-XML) syntax in there is used to build the user interface to specify options to the driver. If you have a range of printers defined, that have multiple resolutions, you can check out just how standardised their UI for resolution is.

I won't claim to be the most knowledgeable or capable person around in this space (a year since I've done any serious Cocoa programming and it was a bit daunting how much I had to look up in the first hour!). I would be UTTERLY ECSTATIC if someone chimed in with an answer - you'll probably hear the "yeehah" all the way over in the USA.

Andy
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://www.realsoftware.com/listarchives/lists.html>

<Prev in Thread] Current Thread [Next in Thread>