About
Code by Kevin: Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.

Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

What is "Mac-native" printing?

As I continue to expand my capabilities with Cocoa and related technologies, I am taking a look at different parts of my applications. One of these features is printing.

At present, I use printing in a traditionally Unix/Tk style: I write output to a temporary file, and then send that file to the printer using the command-line "lpr" tool. Tk supports generating PostScript for graphics output from its canvas widget, and simple text can be saved to a text file. These technologies provide acceptable print output from my programs. The main drawback is that command-line printing does not support Mac-native print dialogs, such as those available in Cocoa. Although I have put together a Tcl script library that presents a nice user dialog for lpr, it's obvious that it's not "native."

It is possible to do native Mac printing in Tk. The late Mats Bengtsson developed an extension called MacCarbonPrint to provide access to Mac-native printing, using the Carbon API's. I have used this extension in my applications in the past. It allows you to take full advantage of Mac-native printing, including saving print files as PDF's, and it provides a familiar Mac user experience.

However, MacCarbonPrint is not perfect. It doesn't handle text printing very well, which is my main need. I contributed a patch to the project that improved text printing somewhat, but it's still not ideal. More fundamentally, MacCarbonPrint is based on Carbon. It would need an extensive rewrite to use Cocoa dialogs. I've looked at the project's code base, and its size and complexity are beyond my skills at the moment.

So my dilemma is this: what do to about printing?

I've done more investigation of basic printing from the Mac-native API's versus using a traditional Tk approach (generating PostScript from the canvas and printing via lpr). A scientific program, SAOImage DS9, actually implements both kinds of printing in their Mac version. The Mac printer dialog is more familiar, of course, but the printed output of graphics from both printing commands is nearly identical. The main difference is the "user experience." Given, however, that MacCarbonPrint actually produces inferior text output to lpr, that takes a point or two away from the "user experience."

On the Mac, lpr is actually a subset of the Common Unix Printing System, the modern Unix implementation of command-line printing. Apple actually owns CUPS, having acquired it a few years ago; they hired its lead developer to continue working on it, and it's still available under open-source terms. Since Apple owns CUPS, I don't think it's out of line to suggest that lpr is as Mac-native as Cocoa printing. (Like Cocoa developers, I'm taking advantage of code that has already been written and debugged by Apple engineers--in this case, however, it's Unix-oriented code.)

In the end, for me, MacCarbonPrint is not a viable near-term solution. The amount of work required for me to port it to Cocoa, relative to the benefits of doing so, doesn't add up. Printing via CUPS/lpr produces output that equals or surpasses the Mac-native extension, with little additional work on my part. I'd rather compromise on the Mac-native dialog than give up reliable printed output.

[/software] permanent link