Good afternoon. I'm Travis Brown, the graphics and imaging evangelist at Apple, and it's my pleasure to welcome you to session 210, which is printing. So what we're going to be talking about in this session is pretty much the culmination of a lot of work that we've been, hard work that we've been doing in the printing system. Because when we originally shipped Mac OS 10.0, we obviously got a lot of feedback at the first WWC three years ago, where developers wanted a system that was far more open and far more flexible.

Even though we had planned long term to build out a lot of these developer features, we heard loud and clear that you guys wanted access to the system now. So last year we actually made a pretty dramatic change. We actually took our printing system and swapped a very significant portion of it to an open source architecture called CUPS, or the Common Unix Printing System.

And this new openness has given us tremendous new capabilities for both the users and developers, things like IPP-based printing, for example, and also an extensible filter architecture that gives developers an opportunity to refactor many classes of applications, such as rips and output systems that can merely be plugged into the CUPS print path.

And what we've really focused on this year for Panther is doing the fit and finish work, continuing how we're integrating these pieces, and then doing new enhancements on top of the integration. So that's what we're going to focus on this session. It's my pleasure to invite Rich Blanchard, the engineering manager for the printing team, to the stage to take you through the presentation.

Thank you, Travis. I think Travis just gave my talk. That was really good. I am the engineering manager for printing at Apple, and I want to thank all of you for coming to our 2003 printing update. I actually have a double thank you for all of you who actually attended last year. Last year, there were a lot of fireworks. I had the dubious pleasure of announcing that we were changing 75% of the printing system and listening to all of you sort of drop your jaws in one smooth motion.

It was very nice. We replaced half of our printing system last year. The whole back half went away. We replaced it with open source CUPS, as Travis explained. Along with CUPS came a brand new printer driver architecture to sit next to the printer driver architecture we had, so we doubled the number of printer driver architectures. Always a good thing.

We rewrote our print center application in Cocoa, so that was a brand new rewrite of our major UI piece that we present to the user. So it was very exciting. There was a lot of concern from the developers that we were changing so much for Jaguar, but we were able to do it, and I was very happy.

After the talk last year, I spent about two weeks having this nightmare that I would have to come back this year, sit back in front of you again, and in my best Yogi Berra voice explain how I was changing the other 75% of the print system this year.

But luckily, we don't have to do that. This year, again, as Travis explained, we're just evolving what we changed last year. We're taking some CUPS features that we didn't have UI for, and we're putting new UI on top of it. Print center is going to evolve a little bit internally.

It's not changing, but you'll see desktop printers back again in Panther. Wow. told you there was a reason we were going to do it. And we're working on the printer driver architecture that comes with CUPS to make that as powerful as the existing printer architecture we had before CUPS.

But primarily, we've been focusing on PDF. If you've gone to all the sessions at this conference, you've heard again and again, especially in the graphic sessions, PDF is what Mac OS X is all about. Mac OS X is built on top of Quartz. Quartz is built on top of a PDF imaging model. A PDF imaging model can import and export PDF documents. For your applications, if you want your application to really do well on Mac OS X, you have to embrace Quartz.

And that means leaving behind some APIs you're probably very comfortable. It means using Quartz instead of QuickDraw. And for printing, it means using the PDF printing path instead of our LaserEyedR8 legacy printing path. Now, that's actually a dirty little secret we have, and some of you may not know that.

There are actually two ways to print inside of Mac OS X. The PDF printing path is our preferred printing path. Its defining characteristic is the fact that after your application is done drawing, the end result is a PDF spool file. Now, your application can draw with QuickDraw. We'll take those QuickDraw calls, we'll convert them into Quartz calls, and Quartz will spool out a PDF for us, and we'll have that PDF spool file. You can draw directly. You can draw directly with Quartz, or you can use Coco's NSDrawing commands, which are implemented via Quartz and, again, spool out PDF. This is our good printing path. This is the printing path we would like you all to use.

Well, if there's a good printing path, there's got to be another printing path. And that's our LaserWrite Legacy Printing Path. This was created for 10.0, and its primary purpose was to ease the transition for our desktop publishing applications that were carbon-based onto Mac OS X. And it did a great job for that. To make it different from the PDF printing path, what's different about this is we actually generate a PIC spool file. This is exactly the same spool file as we generated in OS 9 from LaserWrite 8.

So those desktop publishing applications that were comfortable with LaserWrite 8 work on Mac OS X. It's only available for PostScript printers. The defining characteristics here, the reason people use this, is because they can generate PostScript picture comments embedded within their QuickDraw. And so they only can use PostScript picture comments if they're printing to a PostScript printer.

The next point's a sore one. And I wasn't sure how to get to it. And so the way I usually do a talk, when there's a sore point, I try and distract you. So instead, I have a story. And in the story is hidden this analogy. And I'm going to try and get this right. We'll see. So this story is about two friends, old baseball friends.

They've been friends forever. And it's Bruce and Fred. And they've been friends forever. They've spent their whole lives going to Giants games. And after the Giants game, going home and talking about the Giants game. And they loved it. Decade after decade, they do this. Now they're in their 80s.

They go to a Giants game together. They go to the bar afterwards. They're talking about the Giants game. And Fred suddenly looks concerned. Looks at Bruce and goes, you know, we're getting up there. And I've kind of come to grips with the fact that we're going to be passing away soon. And that's fine. I can do that.

But boy, I'm going to miss baseball. You know, you think there's baseball in heaven? And he was really concerned about it. And Bruce said, well, you know, I'm not sure. And he was worried about comforting his friend. He said, I'll tell you what. We'll make a pact. Whoever dies first will go up to heaven, look around, figure out what the baseball story is, and come back and report to the survivor. And they agree. And Fred felt better.

He died in his sleep, went up to heaven, looked around, figured out whether there was baseball in heaven, sent his spirit back to report to Fred. Woke him up in the middle of the night. Fred wakes up. Oh, my God. He says, don't worry about it. I died. I went to heaven. It's fine.

I checked on baseball, though. Fred goes, oh, well, thank you. What's the story with baseball? He goes, well, I've got good news and I've got bad news. The good news is heaven has baseball. In fact, they play every day. The bad news is you're pitching next Wednesday. So.

The bad news is we have a compatibility path. We have this laser-rider legacy printing path. It's available on Panther. It's been available since 10.0. The bad news is you have to worry about its life expectancy. This is, as of today, deprecated. It doesn't mean it's going away. We ensure binary compatibility for you. That's a big thing for us.

So if your application uses this printing path, you're fine. The deprecated means we're not going to be spending work on this. We're not going to be trying to improve this. If you have a new feature you want on this, be prepared for us to tell you you should really go use the PDF printing path.

So that was the sore point. Everybody get that? All right. So that means we want you to use this PDF printing path. Well, how do you do it? Well, the answer is you don't have to do anything. It is our default printing path in the system. So if you just have a normal printing application, you're on the PDF printing path, and you're fine. And again, you can draw with QuickDraw or Cocoa or Quartz.

To get into trouble, to use the Laser Iterate legacy path, you actually have to do work, and we try and help you get in trouble because we have sample code that shows you how to get into trouble very helpfully. But the idea is when your application prints or the user prints and that print dialog rolls back up, your application makes the call into the print system and says, "Hey, what are the spool file formats I'm allowed to print to given the printer that the user is targeting and given the print settings that he's targeting?" And if the user has printed to a raster printer or selected preview or selected save as PDF, we're going to say, "Hey, the only spool file available to you is PDF, the good printing path." But if they said print and they're targeting a PostScript printer, then we're going to say, "Well, there's two.

You can either do the PDF printing path or you can generate this PIC spool file on the Laser Iterate legacy printing path." And so what you have to do to figure out, and many of you may not know in your applications, whether you're in trouble, whether you're pitching next Wednesday, is to look for this code that's at the bottom. Look for this PM session set document format generation call. Do a grep for that. If you see that, you're on the deprecated printing path, you're going to keep working, but you're not going to be able to take advantage of some of the important features of the system.

What are those important features in the printing system? Well, I'm going to spend a great many slides going over these different benefits. And because you're going to fall into two groups as developers, there are going to be those of you who are on the LaserWriter 8 legacy printing path, and there are going to be those of you who are not, who are on the PDF printing path.

These slides have a dual purpose. If you're using the compatibility printing path, the legacy printing path, the slides are intended to show you how great it would be if you instead switched printing paths and went back onto the PDF printing path. If you're already there, it's a pat on the back, one. Two, it's also a way to tell you some of the features that you can get because you're already on this good printing path, ways you can leverage Quartz and give the user new features.

These advantages fall into six categories. Talk about the unified imaging model you get on the printing path, the ability to give the user a preview from any of your applications and a good preview, save as PDF, always an important user feature, the new PDF workflow feature that we made available in Jaguar 10.2.4, access to Quartz from even your QuickDraw-based Carbon application, and the new Quartz filters, how you can use them.

So the unified imaging model. If you are on the PDF printing path, you only need one rendering loop inside your application. That rendering loop can draw your view of the document to screen, it can draw it when it's printed to a raster printer, and it can draw it when it's printed to a PostScript printer. This is good if you're a developer.

If you're on the LaserWriter 8 legacy printing path, the reason you have that LaserWriter 8 legacy printing path is because your application knows how to generate a view of its document extremely well if it's printing to a PostScript printer, because that's why you're on that path. You're going to generate PostScript picture comments on that path. embed them inside of the Quickdraw.

But you also have to handle this PDF printing path if you're printing to a raster printer. That means you have a suboptimal or a poor rendering path for these raster printers. So you've got two paths and one of them is bad. So we want you, if you're on the PDF printing path, to use that single rendering loop. The other thing is you don't know where your PDF is going to go. You think you're printing, but maybe you're not.

You don't know what's at the other end of the print system, especially with CUPS. We can put all sorts of CUPS filters out there that are combining PDFs or spitting them up on some sort of screen for display before they print. And if you're using the laser-rider compatibility path, nobody's going to be able to show the PDF because you didn't generate a PDF. If you're on the PDF printing path, you can.

Preview, in Mac OS X, all applications get preview, and they get a great preview. That PDF that you spool opens up inside the preview application, which has lots of new features inside of Panther. In particular, it has search capabilities, it has soft proofing. So the preview application's getting more and more powerful.

If you don't know how to generate a good PDF rendition of your document, then what you're gonna get inside of preview is not gonna make the user very happy. The applications that use the laser writer legacy printing path have two solutions to this problem. User hits preview, they ask, what are the available spool paths? We tell them only PDF, they panic, and they raster their whole document, and they give that to us. So you get one big raster image of what they think that should look like. The user gets that in preview, they zoom in, they go, oh, that doesn't look right.

Or they save it, and they go, oh man, where'd those four megabytes come from, right? It was just one text document. So that's a poor substitute for having, or to having a good PDF rendition of your document. Users complain, and so the second step, or second refinement that some of these applications are doing is they're just disabling the preview button. So, throughout OS X, every application has preview, except for yours, 'cause you disabled it. That's not good.

Unix tools are also supported. You can write a Unix tool. We'll be talking about these more later, so I'm going to skip past that. You can write Apple scripts. The Apple script PDF workflow is unique in that the Apple script actually executes inside of the application that's printing.

So if you have UI that you want to present to the user, but you want it to look like it's coming from that application, you can use an Apple script to do it, and the Apple script will run with inside that. And then new in Panther, we have Quartz filters for processing PDF files.

So PDF workflow. PDF workflow tool is any file that is sitting inside that PDF services directory that has its executable bit set and is not an application. Now, you can write these in C, but you don't have to. An executable tool in Unix can be written in these interpret languages that we have built into the system, Python, Perl, Ruby, or even shell scripts. So what I have to do is write one of these scripts, drop it in the right folder, and now there's this new tool available to the user from the PDF workflow pop-up menu.

And the tools actually get a little bit more information than some of the other items we talked about. They get three command line arguments. They get a title, which is the user's title of the document. All too often, that's untitled, so make sure you set your document name if you're writing an application before you print. You get the CUPS set of options. It tells you everything that came out of that print dialog that the user might have selected, and you get the path to the PDF file.

So what's exciting about writing these tools via the PDF workflow is it fits in real well with another technology we announced this week, which is Quartz scripting. And for those of you who missed it, the quick two-sentence description is Quartz scripting is the language bindings for Quartz and also QuickTime and also parts of AppKit that lets you write something like a Python script and call directly into Quartz. So you can take advantage of Quartz without having to write a compiled application.

So as an example, what I've written here is a PDF workflow item, a script, Python script, that will take that PDF that comes out of your application and render, rasterize each page as a CMYK image and store it off as a TIFF. So, you know, that's a pretty serious application.

If somebody asked you to write that and said, okay, take a PDF file and generate TIFFs for it, I don't know how long it would take. You know, it's... Yeah, it's certainly a couple hours, or the four minutes it would take you to actually do it with this court scripting.

So just to walk through this, you can see this first slide. All this code does is make sure it has the right number of arguments. So this is a two-slide example, and the first slide has no content. So here's the real work of creating these TIFF files. First thing you want to do is open up that PDF file that was handed in to you from the print system. So that's CG PDF document create with provider. Now you have this PDF document reference. You're going to loop over all the pages in that PDF document.

Very simple for loop to go through the number of pages. And on each page you're going to figure out how big that page is because you want to create a raster image to hold that document. You create a Quartz context that's backed by a raster buffer. This particular case we tell it we want a CMYK raster buffer, the correct size. And then we tell Quartz to draw that PDF page. And magically we now have a rasterized rendition of that PDF page.

We pick some path, some file that we're going to store the TIFF in. And then again, this is like magic, at least to me. You tell the context, okay, take your bits and write them out as a TIFF file. And you're done. So you can now take this, drop it in your PDF service, and then you can go ahead and print it.

So you can now take this, drop it in your PDF service, and then you can go ahead and print it. and you have this new feature for your user. We're gonna give this demo of this working and some other PDF workflows. Alan Beck's gonna come up and help me out and show some of this. So we're gonna go to demo one, please.

So we have a keynote presentation we're going to use as a demo here throughout our demos today. A little baseball one, somehow keeping with the theme. And the idea is the user might go to the print dialog. And we've populated that PDF service file, so now we have this different look at the print dialog. So you can click on the workflow items, and you see convert to CMYK TIFFs.

So that's that particular workflow. This other demo of workflow I want to do is one that I've tried in two other talks I've given and I've always had internet problems, so this could be the first successful launch of this one. This is an Apple script. It opens up the PDF document in Illustrator. If any of you use Illustrator, Illustrator has this incredible Apple script dictionary for manipulating PDFs. I looked at that thing and I was amazed. It still just amazes me. It's incredibly useful.

So it opens up in Illustrator, walks through all of the text that's in the PDF, takes a text run, gets it, then uses Babelfish on the internet to get a translation for that text run, gets Spanish, pulls it back and then has Illustrator change that text run for its Spanish rendition. So the result is it will convert to Spanish if we have internet access. And it's kind of fun to watch. So there it is, opened up in Illustrator. It goes there, and now you're in Spanish.

And again, a user can do this, or you can write these kind of scripts and provide them for your users. So we're going to try one more, I think. This other demo I like. Generally, these workflow items take that PDF and use it as the source. They optimize it. They translate it. They do something like this.

This other demo is a little different. All I wanted to do today was to show you some text that said WWDC 2003. But that's kind of boring. So what I did is I took the PDF and I used it as a pattern to fill in a background and then fill in the text. And you can see what that looks like.

This one takes a little bit more processing, but not too bad. So we have a pattern. We filled the whole page with that one page from the keynote presentation. It's the background. We used an opacity of maybe 0.2. And then we drew this text. And we drew the text using that same pattern, but with a 1.0 opacity.

And it's kind of cool if you look. You'll see that there's a continuous, because we're using patterns, runs from the whitish areas of the document into the letters, which are now bolder. So you don't have to use your PDF documents as the source. You can actually use them for special effects. And I had some other cool things I was doing with this. I was taking source code and running it through this thing. So you get source code whipping through the letters. Whatever you could imagine. iPhoto was another one. So thank you, Alan.

All right, so we're going to move back on to some of the advantages. We're done with workflow. This is a big one. This is one of the ones where the people who are already on the PDF path don't have to pat themselves on the back. This is one of those advantages you get and things you can take advantage of.

If you're on the PDF printing path, you can draw, or you are already drawing probably if you're a Carbon application with Quick Draw, but you can, if you have new graphics or something, new feature you want to put in your application, draw with Quartz. You might want to draw with Quartz because you want to render a PDF document inside of your traditional Carbon application.

That's pretty cool. You might want to use transparency. Also pretty cool. And it's an easy way for a Carbon application to start transitioning to using Quartz. It's just piecemeal. It's also a great way to efficiently draw. There are some things you can draw much more efficiently in Quartz when they're going to a PDF file than you can in Quick Draw. We're going to look at some of those.

So first, how do you mix quick draw and quartz? We showed this, I think, two years ago first. But it's incredibly simple. You have a graph port, and that's what you're normally printing into or drawing to the screen. That's the quick draw graph port. And you make this call, QD begin CG context. And what you're really saying when you make that call is, well, here's this graph port.

I'm done with it. Why don't you hold on to it for a while? I'm not really done with it, but I'm done with it for now. Give me a quartz context that I can draw into. Your graph port becomes disabled. Anything you draw on there doesn't work. And now you have the CG context, and you have all the CG open to you.

That CG context is freshly initialized, so there's no sharing of state between that CG context and your quick draw drawing, so you don't have to worry about any strange interactions, no pen colors, none of that. And every time you call us, you get a fresh instantiation, so you can draw independent pieces of your drawing without any crossover.

When you're done drawing with quartz, you call CGN CG context. Your graph port becomes hot again. Your CG context is no longer valid, and you can go back to drawing with quick draw. Again, this has been available since 10.1, and we have a very nice sample that's available on the web. on developer.apple.com/printing.

There are a couple things to be careful of when you're mixing. One of them is that QuickDraw and Quartz, they don't agree on which way is up. So QuickDraw likes to have that Y axis running down from the top of the port, and Quartz likes to have it running up from the bottom left of the port.

So this can be a problem if you're not expecting it, but now you are, so no problem. And it's actually very easy to handle. All you have to do is tell Quartz that you want to flip things. So you just have a scale back up to the top left corner of your graph port, and you flip that Y coordinate, and now the two match.

Don't draw text, because it'll be upside down, but everything else will be fine. And text is pretty easy, too. You can use ATS to flip the text scale as well. So two, three magic lines, and all of a sudden you're mixing Quartz and QuickDraw and having some great drawing applications. And this isn't hypothetical.

This isn't something, boy, it would be cool if everybody did. There are major applications that mix Quartz with QuickDraw and do it to generate new features. And this is Excel. I love this example. Their charting package is amazing. It has some incredible shading and transparancy. They do it with Quartz. Even though this is a major Carbon QuickDraw-based application, they were able to mix the two and have this really great feature. So you can do this, too, and they've been doing this since they shipped.

Richard Blazchard: So that's access to Quartz. That's mixing Quartz with Quick Draw. Once you start doing that, you can also start drawing more efficiently because you're using Quartz rather than the Quick Draw. In order to explain how that works, I have to give this brief two-sentence, worth no more than that, overview of what a PDF document looks like. A PDF document is made up of a set of page streams, one for each page in the document.

Those page streams are the drawing commands, what it takes to render that document. But a page stream is allowed to reach out of itself back to this object, X object part of the document, where maybe big parts or big images in particular might be stored. So they can be used out of line so the drawing stream can be more efficient. So you generally get something like this diagram where each page stream has references into this other part of the document, into the object part of the document.

And then we loop over all the documents in the original PDF, the one that's coming from your application printing. We find the bottom right corner. We call begin page in the PDF we're creating. We draw the page that's coming into us. We draw the image. And we call end page. And when this is done executing, you've got a brand new document that is now stamped and is efficiently done.

So images are cool, and images are the most common case of redundant drawing we see in PDFs. And both iPhoto and Keynote both had problems where they were not efficiently using CGM address, and so their resulting PDFs were not as optimal as you might like. They fixed those, and now you get much smaller PDFs out of both those applications, which is great, especially if you're printing contacts out of iPhoto and you print the same thing 20 times. You don't want 20 times 5 megs. It's just not good. But you can do the same thing with PDF drawing. So this is actually exciting.

What you can do is capture a set of PDF drawing, quartz drawing, with CG PDF Context Create. That's a context that anything you draw into it will be turned into a PDF stream. Capture your PDF, create a PDF document from that captured PDF. That's a CG PDF create with provider.

And then wherever you need that logo or that footer or that form throughout your document, you just call CG Context Draw PDF Document, and it will draw that PDF again and again, but that drawing will be shared. So again, that footer will only appear once in the objects portion of the document. And again, you can only do this with quarts.

So our last advantage is something that's new inside of Panther. It's Quartz Filters. And this, again, is the printing guy's rendition of what Quartz Filters are. If you go to the Color Sync session, they'll give you the real answer. This is what I think it is. It takes a PDF document and it breaks it into three streams. They'll tell you there's really four, but there's three. It breaks it into images. So everything out of a PDF document that's an image goes into one stream. Everything that's text goes into another stream. And everything that's vector-based drawing goes into a third stream.

Each of those streams can be separately processed by a Color Sync profile. So you can change the color of images or the rendering intent of images different than you do text, different than you do vectors. The image step or the image stream actually has a second step, which is an image processing step that can do resampling, compression. And then all three of those streams are stuck back together and you generate a PDF file. So this is a way to purpose PDF files.

So you can imagine something that has three different profiles in this Quartz Filter. All of those profiles convert the colors into web-safe colors. The image stream up on the top has a step where it downsamples all of your images to say 100 DPI and then stuffs it back into a PDF. And what that Quartz Filter has done is turned your, what some people will tell you is a big PDF, your digital master PDF, and it's purposed it for web viewing.

So you can do Quartz Filters or you get to use Quartz Filters if you print on the PDF printing path. When you're printing, there's a new ColorSync panel in the print dialog that'll show you an available set of Quartz Filters and allow you to create your own Quartz Filters inside of the ColorSync utility. So you can print and force all your images to go to sepia or whatever else you can think of to create.

We also use it for host-based color matching. When you print in Panther to a color PostScript laser, we can do color matching on the host, which we used to do all the color matching in the printer, which was great. It was device independent and I was a big proponent of it.

It was slow and the printers had bugs. And people would complain. So being a proponent of it didn't save it. So we now have host-based color matching where we can do all this stuff on your faster CPU and do the translations. Preview can also use the Quartz Filters. Save as PDF can use Quartz Filters.

So you can just put one in your PDF services folder, select it, and it'll do whatever kind of purposing you set up that Quartz Filter to do. And that was PDF workflow. So we've got a quick demo. Alan's going to come up and help me again of soft proofing.

This is new in Panther. We're going to look at soft proofing. And we're going to look a little bit at some of the filters that are built in related to ColorSync. Double one, thank you. We'll go back to keynote again. Recognize this document? Let me guess. Let's go ahead and print.

Hopefully we have selected a monochrome printer. Yes. It is a laser R8500. Let's go ahead and hit preview. And here it is, a mono laser. It is showing the grayscale image. And here there's a new checkbox down here. We're going to turn it off. And this is what you would normally get for the preview. And you just turn it off and on again just to see exactly what you get.

Richard Blanchard So what's important here with the PDF preview is we've sent over to preview your digital master. It's captured all of your content. But we've also sent along with it the profile for that device that you were going to be printing to, in this case a monochrome device. And preview can show it either way. It can apply that output profile that would represent your printer and show you in monochrome. Or it can take it off, take that off, and show you what that digital master looked like.

So you can use this also for color printers to see what the gamut looks like on your printer. Somebody likes this. So we're going to look at some of the ColorSync filters now. Go to the ColorSync panel. ColorSync panel. Let's go up and see. Let's go ahead and add the ColorSync filters, which will bring us to the ColorSync utility. And here is our PDF.

There was the black and white, blue tone, I won't say that word, gray tone. So again, what's important here is digital master everything your application drew, pipe through this quartz filter to change what's viewed on screen or what's printed, but we didn't touch your original document. We're going back to slides. So we'll go back over to the slides.

So those were the advantages. Unified imaging model. Your application is easier to write because you have one rendering loop. Your PDFs that come out can be repurposed. The user can redirect them between PostScript and raster printers. Preview. Your users get good preview of your application's drawing. They appreciate that. Save as PDF.

They can capture your document output and reuse it, send it to people via mail or whatever. PDF workflow. They can post-process it and purpose that PDF. Access to Quartz. If you're on the PDF printing path, your application can do more interesting drawing, and you can use Quartz filters, which are going to be very exciting moving on. Thank you.

So why isn't everybody on the PDF printing path? Well, there's two reasons that people generally give me. They tell me they can't get there because their application depends upon the ability to import EPS and to print EPS files. EPS encapsulated PostScript, therefore they need to generate PostScript, therefore they need the LaserWriter legacy printing path so they can generate PostScript picture comments into QuickDraw. So that's one.

The other one is their application generates all its own PostScript. They don't want to deal with Quartz, they just have a PostScript rendition and that's what they want to print. A lot of desktop publishing applications fall under this and more and more of the Unix applications that are moving over to Mac OS X fall under this category. They're used to generating all their own PostScript and that's what they want to do.

Well, supporting EPS is easy. I can handle that first complaint or that first concern. You can go to Cocoa. All right. You don't want to take your Carbon application to Cocoa. But if you did, there is NSEPS image rep, and that'll take care of you in Cocoa. But if you want to stay with Carbon, there is a call, and it took two engineers to type, PMCG image create with EPS data provider.

What that call does is you give it a data provider. This is a way to give Core Graphics the EPS postscript portion of the EPS, and you give it an image rep, which is an image that represents the preview portion of your EPS. In other words, if we can't render the postscript, this is what we're going to draw. It combines those two things up into one wrapper and gives you back this new composite image rep. That composite image rep is smart.

When you draw with that composite image rep, the system, Quartz, will either use the postscript that's wrapped up in the EPS data provider, or it will give you the EPS data provider. Or it will use the preview image. So if you go to screen, say, in Jaguar, because this call is available in Jaguar, it will use the preview.

If you go to a raster printer, it will use the preview. If you go to a postscript printer, it will use the encapsulated postscript. This is incredibly powerful. All you have to do is use this, and all of a sudden you have EPS support, and then you've lost that one reason you gave me why you can't be on the PDF printing path. The Apple Works guys lost their one reason why they couldn't be on the path. So they've now moved.

I don't even remember what version. It was a while ago, but they were one of those applications that complained they needed support. They didn't have support EPS, so they were on the legacy printing path. They used this call, they got off, and now they're a PDF printing application.

Oh, wait, there are some other people who use this call. Again, this is a Microsoft application. I use them because, again, they're a great example of a large Carbon application that's QuickDraw-based. They had to support EPS. They used that call so that they can render. They'll show the preview image here on screen, and when they print this to a PostScript printer, you'll get the EPS output.

So the slightly harder case is the applications that generate all their own PostScript. Well, they have two choices. They can use that LaserWriter 8 legacy printing path. And what they have to do when they do it is take their PostScript, put it in PostScript picture comments so that the printer driver, the PostScript printer driver we have, will intermix its generated PostScript, because it's also converting QuickDraw into PostScript, with the application's generated PostScript. And that's a very complicated, convoluted, lots of other words I could think of, process. And the only way it works is because it worked once.

You fool with your application until it works, and then you stop and you're done. And you can now intermix your application's PostScript with the driver's PostScript. And anybody who's done this, things like SpaceHack and PSBeginNoSave and flushing the QuickDraw state are not a mystery to you. And I apologize that you had to learn all of those things.

It would be better if you could generate the entire PostScript job. That's what you want to do anyway. You'd rather get the driver out of your way. But up until Panther, there's been no way to print that. You generate your whole PostScript job. How do you get to it? Well, we have these new job submission APIs in Panther.

And they allow you to hand a whole file to the print system and say, get this to the printer for me, please. We can't get any file to the printer, so there actually has to be a query you have to make first. PmPrinter, get mime types. You pass in the printer you want to print to.

You pass in the print settings that came out of the user's interaction with the print dialog. And you get back a set of strings that are mime types. For those settings on this printer, here are all of the mime types that you can give us, the file types you can give us. So you scan that. And if you find the mime type you like, PostScript in the case we're talking about, you then call PmPrinter print with file. And you hand the print file in. We'll take it, throw it over into the print server, and you're done.

So what kind of MIME types can we take besides PostScript? Well, we'll deal with PostScript ones first. There's actually two PostScript MIME types that are of interest. Application PostScript. This is what we call non-finished PostScript. If you pass us something with MIME type Application PostScript, we will take the print settings that the user asked for, we will generate PostScript features, and we'll interject them into your PostScript via DSC comments at the beginning of the document.

So this is a way, if you don't want to deal with feature code but you want to generate all your own PostScript rendering, you can use that MIME type. If you really don't want us involved, use application then Cups PostScript. That's called raw PostScript or finished PostScript. You give that to us, and it just goes right to the PostScript printer. We're done.

You can also pass us PDF. If you have a PDF rendition of your document, give it to us, and we'll get it to the printer. Image types, GIF, JPEG, TIFF, lots of different text types, plain, RTF, even HTML, thanks to AppKit, and Cups Raw. Cups Raw is really for the printer vendors, but what Cups Raw says is don't process file at all.

Just don't process file at all. Just send it to the printer. It's usually going to be printer-specific escape codes that you want to send down to have the printer do something specific. And there are lots more. If you actually make that call, you'll get a list of about 20-plus MIME types.

So who would use this? Well, Preview is actually one of the clients on Panther for this. As I mentioned, Preview in Panther is enhanced. Right now, when you click Preview, your PDF document spools. It opens up in Preview. There it is. Preview's got the PDF file that you just generated.

On Jaguar, when you tell Preview to print, what does it do? Well, it dutifully uses Quartz, asks Quartz to render that PDF document into a context, which will create PDF. So you end up going PDF to Quartz calls to PDF. And that's why when you print from a print preview in Preview on Jaguar, your 100-page document, you get to watch it spool as it goes through that conversion for each page. In Panther, it doesn't do that anymore. It's got this file. So it just asks us, hey, can I get PDF to this printer? We always say yes for PDF. And it goes, okay, here's the file. And the user sees no spooling. It's instantaneous.

And it's great. They're also going to do it for PDF files. They don't do that in the seed right now. But for Panther, you'll be able to open up a PDF file in Preview. And when you say print, the file gets copied over to the print server. And that's all. So the big advantage is it removes spool timing from printing, and the users are very happy. That's a dramatic portion of printing times or your spooling times.

All right, so Mac OS X has this PDF-based graphics system. We really want you to use the PDF printing path so you can take advantage of it. If you can't, we have the job submission APIs. They're very cool. We hope they're going to let you get off of that legacy printing path. And if they don't, tell us why they don't. We'll add more API, and we'll do what we can to get you off of that legacy printing path.

Richard Blanchard Once you're off, especially once you're on the PDF printing path, you can grow as the OS grows. Applications that use the PDF printing path, as Panther comes out, or at least Jaguar got PDF workflow with Panther, they get Quartz filters, Quartz scripting, and more stuff in the future as we enhance Quartz and we enhance the PDF part of the system. You get that for free. So hopefully that's a good reason to be over there.

All right, so we're a PDF-based system. We're very proud of our PDF support. But there are some legacy formats. It's actually kind of nice to be up here and call PostScript a legacy format. But that's the way we view it. And it would be great if we had some support for that legacy format in this OS.

It would be great if you could take a rendered EPS and actually show the vector rendition of that rather than that crummy preview that comes with the EPS. It would be great if you could print a PostScript file onto a raster printer. Take that $100 raster printer, plug it in.

Why isn't it a PostScript printer? And it would be good if you were great if you could take a PostScript file and convert it to PDF so you could use the rest of the Mac OS X to handle and process that PDF. And you can. And Panther, and this is incredibly exciting, we have this Panther PostScript converter, and it's a PostScript level 3 interpreter. And it converts PostScript files to PDF. It does not rasterize PostScript. It is not a PostScript RIP. It's a PostScript converter. It does the best job it can converting your PostScript directly into PDF. And that's what we're going to be doing. That's it.

But we do have something in the system that can rasterize PDF. We have Quartz. So you could imagine writing something that took a PostScript file, ran it through this PostScript converter that's now in Panther, get the PDF file, use that resulting PDF file, feed it to Quartz, and have Quartz generate the raster, just like we saw earlier when we were generating those TIFF raster files from PDF. So you could write this, and there's actually Core Graphics APIs to call this PostScript to PDF converter.

I really wanted to show you guys how you could write your own PostScript RIP and I really wanted to do it in one slide, but I couldn't find a guilt-free font to use. So I'm going to give you the two-slide PostScript interpreter. The first slide doesn't do a whole lot. This is a little tool called PSRIP that takes a PostScript file and takes a TIFF base and that TIFF base is the base name that we're going to create for your file. So if you call it out, we're going to create out.1.TIFF and out.2.TIFF.

So the first thing you do is you take that PS file and you create this data provider and that's what Quartz Core Graphics is going to suck on to get the PostScript out of the file. Create a PDF consumer. That's where it's going to write the PDF that it's going to get as a result of converting. We create a converter instance and we pass it the two things. Here's the PS provider to get the PostScript. Here's the consumer to write the PDF, call it.

It'll tell you if it succeeded or not. It might fail, right? There might be a PostScript error. It might not be a PostScript file. It can fail. But if it succeeds, we've got a PDF rendition of that PostScript file. And now all we have to do is get to bits and we have the exact same code we had earlier today to go to TIF.

Loop over the pages, create a bitmap context for each one of those pages in the PDF, draw it, and then tell that context to write out its bits into TIF. And so there's your two slide, dozen line, in Python interpreted PostScript interpreter, which I thought was pretty exciting.

But you might not want to write your own PostScript interpreter every day, although it is easy. We have the converter integrated into the system as well. I mentioned earlier Cocoa's EPS image rep that can show for Cocoa applications EPS files. Well, it now, with the converter, will show the vector rendition. It'll actually convert that EPS file into PDF, and it'll show that PDF rendition. So now Cocoa applications can have this incredible view of your EPS documents. PostScript jobs can be printed to raster printers. We have this great printer server in the system.

And in Panther, it can take in jobs over IPP, LPD, or SMB. So there are lots of ways to get jobs into the system. And now that we have a PostScript converter and then a PDF rasterizer, so essentially you can hook those two things together and get from PostScript all the way to raster for your raster printer, schools can set up a lab, can put in their $100 photo printer, attach it to a client, Mac OS X Panther system, share it, and print to it from Unix, Windows, Mac OS 9.

So you can send that to your Raster printer. So it's great for schools and great for printer vendors, right? You don't have to go license or rip anymore. You shouldn't have to, or should be good enough. And then, of course, the job submission APIs. If you have a raster printer with this in the system, you ask, a raster printer will say, "Yes, I take PostScript." You pass in PostScript, and we'll get it to the printer for you. So that's the job submission API.

And then, of course, the job submission API. So if you have a Raster printer with this in the system, you ask, a Raster printer will say, "Yes, I take PostScript." So, Alan Beck, one more time. We're going to look at some of the places where this is integrated in the system. Cocoa EPS support, which I mentioned, and then opening up some documents.

First of all, let's first take an EPS document and we'll just drag it on to preview and it's going to quickly --

: Okay, see you at bat. And just go ahead and paste it in. See, it is a true PDF image. You can grow it. Let's see, let's rotate it around like this. Then we can even, where is it, show inspector.

Let's just get it correct. There we go. So it is a true PDF image inside Keynote. So an application that knows absolutely nothing about EPS can take the results of an EPS, composite it, rotate it, deal with it as if it were and it is a PDF representation of that graphic. So that's pretty good. But we also have PostScript support. This is a PS file. Let's just drop it on the text edit to see, yes, it is a true percent bang PS Adobe. And we will just drop that onto preview again. It's going to convert it.

We did so good. We were doing so good. That's right. So I'll talk you through that. So what would have happened, Preview got wedged there a little bit. You drag that PostScript document or even double-click it. It converts the whole thing into PDF, and Preview can show you that PDF. Now, PDF has some great new features in it. You can search a PDF document. So you can actually then result in search a PostScript document because it's converted into PDF, and now the search capabilities and Preview is available.

Preview lets you select text and copy and paste out of Preview. So again, you take your PostScript file, convert it into PDF, bring it into Preview, and copy and paste text out of it. Think we're still wedged? We're still wedged. That's all right. Let's go on. That's all right. We'll go back to the slides. You all have your own Panther, so you can try this at home and reboot when it gets stuck.

All right, so that is the PDF sermon. We also have some new APIs that are in the system. This is by popular request. We have this new PM Paper API. We've had a PM Page formatted instance for a while, object for a while. That's the result, the PM Page format of page setup.

When that dialog goes away, there's the PM Page format object that captures the paper that was selected, the targeted printer, the scale, and the orientation. PM Paper is part of that PM Page format, and it's going to capture just the physical characteristics of the paper that was picked. So it's just the physical paper size, and it's just the margins.

There's some attributes that you can get. Again, the ID, the name, the height, the width. And you can get, and this is the important part, the list of papers that are supported by a printer. So if you really want to know what a particular printer supports, what their real physical paper sizes are, PM Printer get paper list.

But what people really want to do is they want to end up creating their own page format for whatever their crazy paper size is. So the steps are create yourself a PM Paper to represent the physical dimensions, and then from that you can create a page format. So PM Paper create lets you create your 12-inch by 2-mile. So that's the first step. paper size. It's all up to you.

Also some side APIs, PPD APIs. Again, this is only for a specific class of applications, but we're installers, in fact. We now have ways for you to get the installed set of PPDs. Once you get the installed set of PPDs and you find one you like, you can ask for one that's localized appropriately for the current user.

And most of our PPDs are compressed. We zip them, and you don't have to worry about that. All you do is call PM copy PPD data. We'll unzip it if we need to, or we'll just give you the raw data if it's available. So these three APIs allow you to do things with PPDs just like we do.

Cups Update. So that whole part of the talk was about the left-hand side of this diagram. It was the user space part of printing. There's the whole right side, which is what we changed last year. It's the Cups D server. It's the print server where your documents go and then start running with all these different crazy user IDs. The daemon running as root and your filters running as this LP user and then your back end's running again as root. That's where your jobs go when they've left your user application.

So what's going on with Cups? Well, for Cups in Jaguar, we shipped Cups 1.1.15. And over the last year, as we were doing Jaguar updates, we've moved back important security fixes and important bug fixes from the Cups mainline, which was going .16, .17, .18, back onto our .15 base.

A lot of people didn't understand this and were complaining that we were stagnating our Cups base. It wasn't true. We just had a stable base we liked, the .15 base, and we were putting important bug fixes on top of it. And because our Cups base is available in Darwin, and because it's live every day, there was no reason for people to get confused. You can go there any given day and see what we checked in any given day.

We went to Cups to be incredibly transparent, to be incredibly open for our developers, and we are. And people should feel comfortable going there and seeing what we're doing. You might have gotten some early hints about facts, and there's some other interesting things you might see as we check things in and out. Panther is moving away from that .15 base. It's moving up to 1.119.

There you go. There's some people who are not happy with just our bug fixes, but that's okay. So all the way up to 1.1.19, which is the latest CUPS right now. If there's a 1.1.20 in the right time frame, I could see us possibly going to that. We pick up some new PPD support. The PPD parser in CUPS is much more strict.

Richard Blazcharg: So, we're building some of our fax support on top of the CUPS's fax support. There's TBCP support, so we can do some better binary printing over different channels. And there's some denial of service security fixes. We picked up almost all of the security fixes that were CUPS-related during the Jaguar timeframe, except for this final batch of denial of service, which we're going to pick up for Panther.

Got this one? Provide fixes. We've been live with our CUPS repository for over a year now, and I've had one person, one developer, send us a bug fix. And it was a great bug fix. He found a real bug in the daemon, provided the fix, we took it, we fed it back to the mainline, and it was great.

And it would be great if some more, especially some of our printer vendors were looking in there and got used to going there to find some answers, because it's all there. In fact, I get a lot of questions that ask me some nuances of the way the daemon works, and the general answer is, well, you know, I don't know. Sorry. But, you know, there's the source. Go look. And I actually had one developer tell me, oh, yeah, it's the daemon. It's the typical open source answer, and kind of blew it off. But no, there's source code. You'll figure out how it works. It's good.

So what are we doing with CUPS? Well, we've got new UI to support some of the CUPS features. CUPS is very powerful. We only bring out certain features, but we have SMB printing support. We're bringing out UI for that. Most of our users wanted and figured out how to do it with Jaguar. That was great.

We have direct socket and IPP printing, so we have UI to create printers based on those. We have printer pools. This is one of my favorites. It's definitely an edge case. But a printer pool allows you to take a set of print queues, bind them up into one virtual queue, and as jobs come into that queue, it round-robin them to the first available printer.

Richard Blanchard I particularly like this because I was at Siebold a year and a half ago, maybe, and a professional photographer came up to me and said, "Hey, you know, I really like CUPS. I like what you've done, but I've got these eight photo printers. They're all identical, and my job depends on printing as fast as I can to these printers." Richard Blanchard And so here's his answer.

It's coming in Panther. He'll be able to just print to this virtual pool, and he'll find the first available printer, and he can get all eight of his printers going at the exact same time. It's a very cool feature. And then TBCP will have UI to enable that.

We're adding a lot of new support for CUPS-based printer drivers. As I mentioned earlier in the talk, we have two printer driver architectures. We have the CUPS-based printer drivers and we have the older Tioga-based printer drivers. We're working to get the CUPS-based printer drivers so they have the same, if not more, set of features that are available in Tioga. And primarily we're doing that by adding some new support for some new PPD keywords. Here are four of them. They allow a CUPS-based printer driver to specify the color sync profile that color should be converted to before it's handed to it.

Richard Blaencharg What's really great about this particular implementation is that you can provide a CMYK profile. So you can say, here's my printer driver and I really want colors in the CMYK space. And if the application draws in CMYK, we will get those CMYK colors all the way from the application to the printer without going through any RGB knot hole, without any of these funny conversions. It's CMYK all the way to CMYK if that's what the application started with.

We have a new link in the PPDs for print dialog extensions. So a CUPS-based printer driver can now have its own UI in the print dialog. It can link to a printer utility. So the user in the printer setup utility can click on a printer and say, hey, launch the utility. And we'll know which utility you want. And it can have an icon. You're not a printer driver until you have an icon.

Going forward, we're going to be focused on CUPS-based printer drivers. We're going to support the Tioga-based printer drivers, but that's not our focus. We're going to be putting all our effort into the CUPS stuff. We're going to be making that more and more powerful. So if you have a Tioga-based printer driver, we're not going to leave you behind.

We're not going to purposely break you, but we want you on the CUPS printing path, especially for some of your new drivers. And if there's something there, something you do with the Tioga printer driver that you can't do with the CUPS printer driver, please let us know, and we'll work to fix that.

There are a couple open source printer projects that have been great for us over the last year. GIMP Print and HPIJS are two of them. Open source projects generally, because the vendors do a good job supporting their most current models, are important for some of the legacy printers.

But because they're CUPS-based printer drivers, they also allow the user access to some features that are only available for CUPS printer drivers. Most of the printer drivers available from the major vendors are the older Tiago-based printer drivers. GIMP Print is in Panther. This was a big deal. I have a huge thanks that go out to the GIMP Print team. Robert Krawitz, who organizes that team and runs it. It's an incredibly vibrant team.

They have a SourceForge home. Lots of bug reports go in there. They address them incredibly quickly. In fact, if any bugs get stuck, it's because they're usually assigned to me. Their team is great. There's also been this incredible support for the Mac OS X version of GIMP Print, which means a great installer, de-installer, documentation.

And that's all been done by Tyler Blessing, who's favored us all this week with being a VIP for us and coming to the conference. You see him in the hallway, make sure you thank him. By himself, he's brought support for over 500 printers to Mac OS X. That's one man.

So we had printing in 2002, changed the whole print system. 2003, we're just evolving. What are we going to be looking forward in 2004? We're going to keep our focus on PDF. We're going to bring more and more new features, more and more optimizations to that PDF printing path.

If you want new features, please get on that path. Please let us know what great features you'd like out of PDF. File size is one we always hear, but if you have other things, please let us know. CUPS 1.2, that's still out there on the horizon. When it's available, we're going to be moving to that.

CUPS 2 offers some important accounting features, some back-end bidirectional communications features. It's going to be incredibly exciting. There are-- well, there's a source tree. You can go out there and see what's already been done and follow it. And we're going to be focusing on CUPS-based drivers. So that's going to be 2004 when I come back.

For more information, we actually have a lot of printing documentation. Just to give you a quick overview of it, we have the overview of the printing system. It's a little dated, but most of what's in there is true. We have separate documents for supporting printing for Carbon and Cocoa. We have documentation for writing print dialog UI.

references for the Carbon printing and for writing plugins, descriptions of how we use PostScript printer description files. So if you wonder how we use PPDs, there's a document that explains it. How to create presets for iPhoto, how to use the workflow feature and how to write new workflow items. There's the CUPS software programming manual if you want to know how CUPS itself works below us. And then there's our developer site, developer.apple.com slash printing, and there's just a lot of documentation off of that.

So please go to these references. I think you'll find a lot of interesting documentation, and then we have some good sample code as well. Sample code will show you how to use Sheets. That's always a great touch. How to mix Quartz with your Carbon Quickdraw application and a PDE project, how to write a print dialog extension. So please go look at those. Travis, I think, will come up and talk you through the roadmap.

Thank you, Richard. Actually, what I'm going to do is, since those were some pretty long URLs, since we only really have one day of sessions, I'll skip to that, and then I'll go back to the URLs. We can be in the Q&A so you have time to copy them down.

So we're pretty much left with just Friday's sessions, which a lot of them are going to be, for example, court services, which relates to essentially managing displays on Mac OS X, and that's Friday morning. Then we have one more OpenGL session, this one hosted by ATI, who is our hardware partner, who's going to be showing us all the latest visual effects you can accomplish using their hardware and programmability. We also have a session on Mac OS X accessibility. This will be an interesting session.

If you want to ensure that users with disability can successfully... use your software. And then obviously we have the feedback forum where you can feel free to come and give us feedback on the sessions, and also questions, issues you have with Mac OS X printing in general, that we can often incorporate into our planning for the next major release of Mac OS X. So let me invite the printing team so we can get our Q&A going.