Welcome to the first of two printing sessions, printing on Mac OS X and then advanced printing on Mac OS X this afternoon. Printing is a very, very vital part of any operating system, because you can have the fanciest graphics and have the greatest programming language and frameworks there, but it don't mean squat if the customers can't get their results out on paper.

And it must look good, too. In fact, actually, it was the combination of, back in the early days with the Macintosh, the combination of the Adobe PostScript, all this page maker, and the Macintosh that really has really kicked off the desktop publishing revolution. We need to continue forward in making printing easier for both the customers and easier for printer driver developers and easier for application developers to implement. And we think we're taking a good stride towards that goal with the release of Mac OS X and the Tiogo printing architecture.

So to talk about the printing architecture from both an application and a driver point of view, and to go over the architecture overall this morning, I'd like to introduce Paul Danbold, the manager of the print group at Apple Computer. Paul? It's been quite a few years since Apple had two printing sessions at this conference.

So what we're going to do in this one, we're really going to be talking about what you can and should be doing with all the latest printing APIs. And we'll be covering a couple of new topics. One's document modal printing, which you'll see in a moment, and displaying your print dialogs as sheets, and a better way of extending the print dialog for both application developers and print driver developers. That'll take us halfway through the session, and then we're going to talk specifically about Mac OS X printing. I'll take you through the architecture, which hasn't changed a lot since last year, and I'll be explaining what's in DP4 and what to expect in future releases of the OS.

So, here's the situation with Carbon printing on Mac OS 8 and 9, for those of you who are carbonizing your applications. Your application is up there, as you can see. You may have your handcrafted printing code, or you may be using a Carbon power plant or Carbon Mac app.

You're using the APIs in the Carbon Printing Manager, which is part of Carbon Lib on 8 and 9. And the way to think about it is that the Carbon Printing Manager in that environment is just a little bridge between you and the classic interface to print drivers. And print drivers do most of the work. The situation hasn't changed there. They have the chooser pack for printer discovery. They do the page setup and print dialogues.

They turn Quick Draw into whatever page description language the printer supports. They talk to the printer, etc. They handle foreground and background printing. So, Carbon Printing on 8 and 9 is no different, really, than it is with the classic printing system in that the code that we provide is a thin bridge. There's the chooser, and there's print monitor or desktop printing for spooling.

One of the things, if you've looked at Carbon Printing on in CarbonLib, and hopefully many of you have, you'll see that the header files, actually there's two now, or three actually, contain a lot of APIs. About six times as many as in the original printing.h file. And one of the things I'm going to try to do in this session is explain why we've got so many APIs.

One of the reasons, the obvious one, is that we cleaned up a lot of things, so you now have access to functions to what we call the page format and print settings objects, which replace the old print record, which you were used to access directly. We have convenience utilities or functions to get at.

To insert pic comments and to do PR general type functions. But since last year, we've introduced a parallel set of APIs which account for almost half the APIs in those headers, which take a print session argument. And we'll be talking about why we've introduced all those extra APIs as we get into this session.

So Carbon Printing Manager, as I said, is a bridge to the classic printing interface. The drivers still do most of the work. It's worth dwelling for a moment on the third bullet item here. What we've done in Carbon Printing is we've provided some APIs which allow you to do things like get and set the page orientation, the page size, the scaling, etc. Because a lot of applications actually have a good reason for wanting to find out what's in the print record and maybe manipulate it. It certainly isn't for all applications.

And we had to find a reliable way of implementing those APIs. The issue is that different drivers store their settings in different parts of the print record and encode the settings differently. So a year ago, I said we were going to take care of this and relieve you of the chore of writing a lot of special case code to deal with different printers. And I thought we were going to do this programmatically, but we've changed our tack here.

And last year, we started to work on a database that we're putting into CarbonLib. And that database will contain for as large a number of drivers as we can find information, basically offsets and encoding information, so that when you call PM, set orientation, for example, or set scale, or set color mode, or whatever, we will be able to execute that reliably because the printer vendors have provided us with the information so that we know where those print drivers store the information in the print record. That's a work in progress, but we're fairly confident that it's a better solution than the programmatic one. And if you happen to be running your Carbon application on a print driver and it doesn't behave correctly when you call some of these calls, you should let us know.

So here's your same application running on X. Of course, it could be a Cocoa application as well as a Carbon application, because everybody calls through to the same printing APIs. Underneath those APIs, of course, is a very different implementation. And that implementation is inside the printing frameworks. There's actually two. I'll explain that in a moment. And they're covered by the Carbon umbrella framework.

What's significantly different is that, as opposed to print drivers serving up the print dialogs, for example, and generating their spool files and doing all that hard work, we're doing a lot of that now in the system. So we provide the page setup and print dialogs. We generate the spool file. We send the print job to the print server, which is a separate process.

The last thing to mention on this slide is Print Center, the application, replaces the chooser, replaces desktop printing. It provides the UI for discovering printers, for setting up and managing queues. And it actually loads these modules, called printer browser modules, to do connection-specific printer discovery, like finding printers. over an ApiTalk network with MVP, or going to the NetInfo network database to find printers that you may be able to talk to with LPR.

Last year, if you were here last year for the printing session, you heard me go on about all the Carbon printing APIs. And, tempting as it is to repeat that, It's better for me just to point you to the latest documentation. If you go to this URL, where most of the Carbon documentation is, you'll find that all the printing APIs are pretty comprehensively documented. The documentation was actually updated this week, so if you are working off an older version, you should download the latest.

You'll find in there a pretty comprehensive explanation of all the concepts behind Carbon printing, all the functions, all the type defs, etc. And so instead of talking about the APIs, what I'm going to do is invite Alan Beck from the printing team to come up and show you them in action, and show you printing on X today.

There we go. So basically what I'm first going to show you is Print Center app. It's like Paul said, it's a replacement for both Chooser and the desktop print monitor, or desktop printing stuff we had. So basically right now we don't, if you can see here, we don't have any printers in our work set. So basically I want to go and browse for some printers.

So basically I'll first say I'll go see if I can find any USB printers. Here's an Epson USB printer that's connected to our demo machine here. I'm just going to add that to our work set and let's see if we can find another one. Let's go up to Apple Talk.

Let's see, what do we have here? We have a couple of LaserJet 4500, and I'm just going to go ahead and add that to the workset. And let's close this. So here, basically, here's my workset, something we use as desktop printers. You can do the same things that you can before. Go up to the printers menu. You can actually go to the queue. You can stop the queue. Let's go ahead and stop this queue.

And let's go ahead and make that one our default printer. As you can see, your default printer shows up here. You can see right now we're using the old icons. It would be great as for the printer module developers to create these wonderful new 128-bit wonderful icons to impress our users. So let's go ahead and close that. Let's go ahead and quit out of print center. We have all of our printers set up. And let's just go down into simple text.

And here you can see normal simple text document, fancy new picture shown. And let's just go ahead and bring up page setup. Here's the page setup dialog. You can see it takes off of the panel-based UI of LaserWriter 8. One thing you should notice is it is a movable modal dialog now. You can basically select paper size of any papers that the printer supports. We have orientation, you know, portrait, landscape, and we're also providing a button for reverse landscape, as well as scaling. So let's go ahead and do that.

Actually, one last thing here is like you can format for your different printers. Like here, it comes up to a default printer. So if you just click this, you can go back to the USB printer, or you can select other, and it will launch Print Center, and you'll be able to add more printers to your work set. This pop-up menu only shows the printers that you've added to your work set. Then let's go ahead and bring up the print dialog.

Here again, you can basically have, you can say what you want to print to. Here again, with the same pop-up, this is the page setup. But this is the actual printer you're going to print to. We're going to stay to the LaserJet. The next item down here is Save Settings. This is what we expect most users to be doing. Basically, it's a save settings of all the settings that are down in the, that the user has set.

Printer driver, printer module developers will come up with their own, and they will be shown here. Like, we have like photo glossy, normal color, normal black and white. And the user will be able to save different sets. You can see here, they'll be able to come down here and save what the current settings are.

into a-- it'll be saved for them. And then those settings will show up in this popup as well. So we don't expect many users to be actually navigating the panes and setting all the different options. They will basically do what they want-- set it once, save the set, and then just basically switch between the settings. Then we go to the popup menu. Basically the same as some of the old drivers, copy some pages, be able to set these, set the page range. Another thing we have is we have layout as a standard feature for all drivers.

So basically any-- Any printer will be able to have this. You can set your pages per sheet, the layout direction, and what type of borders you want. Another thing we have is this version of Simple Text uses the old append-diddle mechanism for extending the dialog. So basically you will see they have their own pane and name the name of the application. Here we just added two sample ones. This is basically print selected text only and include page numbers. Another thing we have added for OS X is basically a summary pane of all the current options that the user has selected.

So here's basically a summary of what the user, all the different panes that the user has selected, except for the app pane. Because we do not know at this point, because the application uses the pen diddle mechanism, we don't know what they have set. And there is an API to get that.

Let's just go back here and let's just go ahead and... Every print dialog has a preview feature. Basically, we select preview and it'll do a preview. What it's doing is saving that PDF to disk and opening that PDF file with your preferred PDF viewer that the user has set.

So here you can see it's, there's the document, we said include page number, so here's the page number at the bottom. One feature of this is now that we're in PDF, or preview, you can actually go to and save this PDF file as a document anywhere on your disk and use it for later processing. Let's just go ahead and quit out of this.

Now we're back in symbol text. Let's bring up the print dialog again. And let's just go ahead and actually print this. Let's quit out of this simple text. We have a new version of a different version of simple text up here. Let's just go ahead and open up this version of simple text. And here we have, let's get two windows up.

Let's go ahead and print this. Let's go ahead and try to print this. And what you can see now is we have the print dialog as a sheet. And so basically everything is active here, layout, summary, all that stuff is there. What's nice about the sheets is you can go ahead and go over to this document and try to print it as well. So you can have two print dialogs up at the same time. They are independent of each other.

So basically I will say, you know, I want, you know, five copies of this. And let's go to the summary pane of this. It says five copies here. And basically, you know, it's not reflected over here. It still says one copy. So they are totally independent of each other, and you can print these as you want. So this version of Simple Text also, as well as using Sheets, actually use the new mechanism for extending the dialog, which is through a PDE extension, print dialog extension. So basically here it's much more flexible to the, much more flexible for the developer.

You can get any number of panes that you want. You can organize them in any way you want. So you can have multiple panes being added for the user so that it's not all kind of crammed into one dialog. Another nice thing about this is You actually get the summary presented to the user through the PDE interface.

Another thing that this one has is, you can see here, let's say we want to print this to the inkjet, it goes back to copies and pages, and here this printer module actually added its own PDE, and where it can select print quality. And that as well is saved in the summary. You can see that in the summary as well.

Is there anything else? Pages. Okay, let's go back to, let's quit out of this. Actually, another thing I wanted to show you is this is a true sheet. This print dialog is up. You can't do anything in here, but this dialog here is purely active, if you wanted to do that.

Let's go back to the Print Center app. Let's go ahead and look at this, see if we can see. Okay, here's the document I printed earlier. This is a picture of the OS desktop. Let's just go ahead and start this queue. It should be printing now, if I remember. Let's see, yes.

It now says it's printing. In future versions of PrintCenter, we will be displaying a lot more user feedback to the user, you know, in this area up here. And actually, it's, the printer is starting to print. I hear it up here. And here is the document that I printed.

So although this afternoon we're going to go into code level details about how that second version of Simple Text was able to do what it did, I'm going to cover briefly the steps you should take as an application developer to get to that level of printing functionality. We'll start with, we'll take it in three steps. The first step many of you hopefully have done, and that is to do the carbonization of your applications.

And if you started with the APIs that were available back when CarbonLib 1.0 was released, for example, and earlier versions of 10 were released, you will have done that work, should be fairly straightforward, PR open, went to PM begin, etc. And your application is running on 8, 9, and 10.

When you do that, the user experience, as far as saying print dialogs, is what you saw in the first version of simple text we showed. Print dialogs are still modal. They're sort of modal for the system on 8 and 9, and they're modal for the application on 10.

So, step two is worth talking about in a little bit more detail. When Aqua came along, which I might say was after we designed the first set of Carbon printing APIs, we realized we were going to have to support document model printing. And we looked at a lot of different ways in which we could Implement that and minimize the overhead to you if you'd already done the basic carbonization work.

And after a while, we realized that the best thing to do was to introduce a parallel set of APIs and add one new argument to that parallel set. And that argument, which is a printing session object, enabled us to maintain context between one document's print session and another document's print session.

So although I hate to ask anybody to go back and rework their printing code, this rework is rather straightforward. You have to be a little careful to make sure that you're doing the right thing. But switching over to the session APIs will get you to the point where you can have multiple print sessions running on 10. Because ACWA doesn't run on 8 and 9, as you're probably well aware, you are limited to one session on that OS. You can use the session APIs, you're just not allowed to create multiple printing sessions.

So if you do that, basically you've got the ability to run, to spool a print job while another one is being prepared. So you've got some performance benefits. But your print dialogs are still modal. They're not displayed as a sheet. So you're going to take one more step, and that step's pretty straightforward. It involves one new API, PMSessionUseSheets. It involves a callback function that you have to reference from your call to PMSessionUseSheets. And when you do that, basically we'll display the print dialogs as a sheet for you. And everything works like it did in Alan's demo.

We would like you to get there as soon as you can, but we understand that if you've already done the first step of getting your applications carbonized, you may want to wait until 10 is your primary focus before doing that, because you are going to have to do a runtime check before you can use this API.

The other thing that Alan had in the first version of Simple Text was that he had Simple Text adding a couple of controls to the print dialog using the old append-dittle mechanism. And if you don't know what append-dittle is, you should look at TechNote 1080, I think it is. It's been used a long time and will continue to support it and maintain it on both 8.9 and 10 with Carbon printing.

It has some significant limitations, I mean, one of which is that, especially on 8 and 9 with different drivers, you don't really have a lot of control over where your controls get placed. And two, all your controls just go into the print dialog. There's no ability to organize them into multiple panels. And there's no way for your controls to have any idea of what the system, the printing system's controls are doing, or what the driver's controls are doing.

So, as Alan mentioned, we've come up with a better mechanism. We call them print dialog extensions. They're plug-ins. They're based on CF plug-in. And because They tie in quite nicely with document mobile printing and printing dialogs as sheets. They are available only for 10. As I said, you can use them when your print dialog is displayed as a sheet.

And the benefits are that, one, if you have a lot of printing features that you want to add, you can organize them into multiple panels. The way to think about it is that you write one PDE, one plug-in per panel you want to add to the print dialogs, or to the page setup dialogs.

So that's good. One thing that's got incredible repercussions potentially is that your controls can override other controls. We've let applications install PDEs which override things that we provide as standard in the system. You can even override controls potentially that the printer driver would serve up. So you have to be careful about this, but if, for example, your application wants to allow users to type in page numbers or page range in a different format than the one that we provide, then you've got the ability to do that. And you won't confuse users by providing two page range controls. The other thing that we're implementing is a mechanism to notify your PDE when a control in another panel has been changed that affects you.

Of course, you have to be a little careful about doing that, but it's a lot more powerful than what we used to have in the past, where you might implement, for example, the reverse page order control in your print dialog. The driver may have done the same control, and they'll interact with each other in ways that the user probably won't appreciate. If you want to know exactly how to write PDEs, you should come to this afternoon's session, because I'm not going to go into code at this time.

To wrap this up though, the main message for you is if you're developing a Carbon application and you've already done the port, the non-session APIs are just fine for now. You'll print on 8, 9, and 10, but the print dialogs will be modal. Very soon, hopefully 10 will be your primary focus, and that's the time when you should switch over to the session APIs, use those. And a small step beyond that would be to display your print dialogs as sheets. And if you're an application with advanced printing needs, now's the time to think seriously about using the plugins instead of using the append-dittle mechanism.

And that's pretty much it for the first part of the session to talk about Carbon printing APIs. We're now going to switch over to a quick recap of the printing architecture on X. If you were here last year, you saw a diagram that looked just like this. And the good news is that it's still a valid diagram. We haven't changed our architecture.

We've tweaked a couple of APIs, but pretty much everything's in place. We've just written a lot more code. I'm going to walk you through this fairly quickly, and the reason I'm going to do that is so that I can point out what's in DP4, and what you can expect in the first release of X, and a couple of things that will unfortunately have to wait until future releases of the OS. There's your application up on the top left, Carbon or Cocoa.

You're going to be linked against, well probably against the Carbon Umbrella Framework, but you're certainly going to be linked against the printing frameworks which are inside that. And as I said, print frameworks are responsible for serving up the UI, they're responsible for generating the spool file, they even talk to print center, and they replace a lot of the functionality that old style classic drivers used to do. They generate a, for every time you hit the print button, they generate a print job.

The print job, as I talked about last year, comprises two files. There's a spool file, which by default is PDF, but other spool file formats are supported. There's also a job ticket, which is a metadata associated with a print job, which provides a better means for us to control printing as the job goes down the pipeline, and to separate the PDL, the page description language, from the printing setting. things.

So the next step in the pipeline is this separate process called the queue manager. If you're running Process Viewer on 10, you'll see that it's called the print server. And it replaces print monitor and desktop printing that you're familiar with on 8 and 9. It's responsible for managing the queues, multiple queues for multiple printers.

It's designed for a client-server architecture to support a client spooling a job and sending it to a separate machine to process. But in DP4, and unfortunately in the first release, we're only spooling local queuing. The design's there, but the implementation isn't ready for us to be able to support true client-server printing.

The job manager is responsible for processing individual jobs as they get dequeued by the queue manager. The job manager is responsible for page level features. For printers that don't have their own ability to do things like print multiple copies, it takes care of that. And it coordinates three threads. The first one is the converter. The converter is quite a clever piece of code. It's not just a single module. It contains code that can read in various full file formats, and separately code that can generate different output formats.

The mainstream print path is when the print job creator uses the converter to generate from, say, Quick Draw, a PDF school file. And when you get down to the server end of the system, the converter is used to convert that PDF into bitmap. And the converter is built around a lot of core graphics technology to do that.

But also in the converter is code ported over from LaserWriter 8. So, for example, if your application generated a school file that contained PostScript, we would generate an old-style PIC with PostScript school file. And by the time the converter gets to process the job, it's going to be using LaserWriter 8 code. So, you're printing LaserWriter 8-derived code to turn that into PostScript. Of course, that seems you're printing to a PostScript printer.

The printer module is really the vestige of the old drivers. It contains all the printer-specific code in the printing system, because the OS is taking care of so much of the functionality. And it's a printer module that is responsible for knowing what sort of format the printer is capable of receiving, managing the printer, returning status up the pipeline, and error messages up the pipeline to the client.

And I'll be talking a little bit more about the printer module in a moment. The I/O module, as I mentioned a moment ago, we've separated I/O from spool file rendering and that sort of thing. I/O modules are shared amongst various types of printers. We have got I/O modules for network protocols and I/O modules for the Direct Connect protocols like USB.

Last but not least, we've got the Print Center application, which you saw in action. UI isn't final, but it works just fine on DP4 for discovering printers, setting up queues, and picking default printers. But we're going to be extending the functionality so that it becomes a host for printer configuration and other things. So you can expect that to evolve between now and the first release of X.

So that's pretty much the architecture, and I'm going to switch over here to show you the Toga system from the viewpoint of printer vendors, or the developers of print drivers. It's a slightly different perspective because here we're showing four types of modules which Printer vendors or driver developers are going to create, with an SDK, which we're going to be releasing next week, to be able to get their printers working with Mac OS X. And we have been collaborating with a lot of printer vendors over the last year. If you're in the business and you haven't been talking to us about your needs, next week would be a great time to get in touch with us.

Let's talk about printer modules first. What do they do? They're quite simple actually, or maybe that's just because they're architected cleverly. They have a set of functions that are used to tell the converter what sort of output data they want the converter to generate. They contain, obviously, codes to know how to format the data for the printer.

In the case of an inkjet printer, they'd be banding the data and compressing it and inserting engine control codes, etc. They also have the smarts to handle printer status and error messages. They're called by the job manager. When a job's being printed, the job manager will tell the printer module to print a page or maybe print a whole document and relay status, etc.

It's a lot less work to write a printer module than it was to write a classic driver, by a long way. So what Apple's doing, and what we've done for DP4, is we provided the PostScript printer module, so we take care of most of the PostScript printing needs.

We don't have in DP4 full support for PPD files. That'll come later. But Apple is taking on the responsibility of providing PostScript printing support in the OS. And printer vendors will be using the SDK, which I mentioned, to write printer modules for their printers, which sort different page description languages, like PCL, which you've probably heard of, Escape P for Epson printers, the BubbleJet language for Canon printers, etc. So we're looking to those printer vendors to write printer modules for those types of products.

Print dialog extensions. You saw one in Alan's demo. In just the same way that applications can add functionality to the page set and print dialogs, printer vendors and basically printer modules can expose their printer-specific features through these plugins. So, not only do you have the printing system, that part of the OS, putting up controls in the print dialog, you have applications potentially doing it by installing their own PDEs, and you have the printer modules registering their own PDEs.

We're going to do all the basic, what we call universal features in our PDEs, so copies and page range fall into that category. We're also, after DP4, but before we ship the first release, going to add these plugins to support PPD features for PostScript printers. And we're going to be looking to the printer vendors using this SDK to write these plugins for their features. We categorize these features using some terminology, which I might as well mention now.

Universal applies to features which you always get, regardless of what you're printing to, and copies and page range are good examples. Standard features, features like quality mode, if you've got a printer that supports best mode or draft mode, etc. Different printers want to implement quality mode using a different style of print. So, because there isn't a standard way of presenting that, we would expect the printer vendors to develop those panels for what we call these standard features. Then applications can add their PDEs for what we might call custom features.

So, for example, with this presentation package, if you wanted to print out slides, notes, and handouts, you'd expect to see a panel loaded for that application's custom features at print time. And then last but not least, the printer vendors are going to use this SDK to develop those panels.

So, we're going to be looking at the different types of features. So, the printer vendors are going to be writing PDEs for their unique features for their printers. So, Apple's going to be taking care of PostScript, and the printer vendors are going to be writing PDEs for their non-PostScript printers.

Printer modules and PDEs are mandatory to hook a printer up to 10 and be able to print to it. I/O modules and their counterpart, which is on the next slide, those we're hoping that printer vendors and other developers really don't have to spend a lot of time on, because it's our intent to support the mainstream print protocols.

In DP4, we've got I/O modules which handle printing over LPR. AppleTalk with Pap, we can send

If you're using a printer connected up to Mac OS X, and for example it has an interface that we haven't supported, then you should talk to us before you go ahead and write an I/O module for it.

Because we'd like to help you. But there will be cases where you have a proprietary interface maybe to your printer. If that's the case, then the SDK, through the SDK, we will provide sample code for you writing your own I/O modules. And I mentioned a couple there that possibly Apple would do, SCSI and IRDA, but it's not high on our priority list.

The last is printer browser modules. These are, to I/O modules, what print dialog extensions were to printer modules. I/O modules have no UI. If you want to find a printer on a particular connection type, Print Center loads a printer browser module to give you the user interface for the discovery process.

So we have, for example, in DP4, we've got a printer browser module so that you can set up an LPR printer. And as you probably know, LPR is not a BiDi connection. So the user interface for LPR is that you type in the IP address of the printer.

We have another one that Alan showed, NBP, that's the AppleTalk discovery protocol. So we have a printer browser module. We have a printer browser module for connecting to AppleTalk printers. Netinfo, which you're probably familiar with, which is a directory service, we have a printer browser module so you can find printers in the Netinfo database. And last, and of course not least, is USB, and you can find printers on your USB bus. So in due course, we'll have a printer browser module for FireWire printers.

Another one on our list is SLP, Service Location Protocol. Again, it's not in DP4, it's likely not going to be in the first release, but it's becoming quite a popular IP-based discovery protocol. And as people move more and more towards IP-only networks, we'll add SLP to enable you to find SLP-savvy printers. And just like you might have to write your own custom I/O modules, if you were to do so, you'd be writing a printer browser module to go along with it.

The print dialog extensions, I/O modules, and these printer browser modules, these are all part of the so-called Tioga SDK. The SDK is focused right now on the printer modules and the print dialog extensions. It's coming out next week, and as I said, if you're not already talking to us, you should be.

I could say how great this SDK is, but actually we've been working with some of the main people in the printing business for the last year. In fact, a year ago next week, we got together with them and started the collaborative effort of creating this SDK. And we've been making some pretty good progress over the last year.

They've been very helpful, supportive, and patient with us. And so we thought that we would get some of these guys who've been collaborating with us to come up here and just tell you what their plans are for supporting Tioga on X. And I'm going to hand over to John now to make those introductions.

Thank you, Paul. As Paul mentioned, we have been working with developers. We have not been designing this in a black box. We have been taking feedback. And we've been very lucky that we've actually worked very closely with some of the key printer developers out there to get some very good feedback. And the results have been extremely positive. So I'd like to first introduce I'll introduce the three that we have reps today. I'll first off with Rick Spillers from HeLa Packard to talk about where they're going with Mac OS X and their printers. Rick.

Hi everybody, I'm very glad to be here and I just want to say that I'm part of a small team inside Hewlett Packard that's focused exclusively on the Mac market across all of our product lines. It includes our large format design jets, our laser jets, and especially our award winning desk jet printers.

Since the iMac first introduced a few years ago, we've been working real closely with Apple on an R&D level, and especially in the last year, as Paul says, our software engineering teams have been working with Apple to make sure we're on track with OS X development. And that's been working out very well.

And we have some very hardworking-- Mac-focused software engineers, many of whom are in the room right now on our quality assurance team that's working real closely with Apple to make sure our OS X drivers work well and we're ready to ship things in the box as OS X develops. We're very excited inside HP about Mac OS X, and it's really raising some eyebrows inside HP with all of our Wintel folks, so it's really interesting to watch that from the Mac perspective.

I also want to ask that, from a developer standpoint, as you develop your products for OS X, you think about HP, and to help you do that, HP has a website, hp.com/go/solutions, where you can sign up on a couple of different levels to get HP products to test with for your OS X development, and also to get HP products to use at trade show demos and things like that. So that's available to you, hp.com/go/solutions.

And in closing, I just want to say that we're very excited to be working with Apple. I think OS X is going to be really hot, and we're working hard to make sure we have OS X drivers that are going to ship in the box with our printers as things roll on. So thank you.

Thank you, Rick. Next, I would like to go ahead and introduce from Epson, Mitch Kadish. Thank you, John. It's great to be here. The relationship that Epson shares with Apple is a very important one for us, and it's also been a continuous one, even through the tough period that Apple went through a few years ago. As you probably know, when the iMac was introduced, Epson was there with the first USB printer, and we continued our innovation last year by introducing the first FireWire printer.

We're very excited about working with Apple on OS X, and you can be sure that when it ships, our drivers will be there fully supporting all the printing features in the operating system. And we're especially excited about the Tioga architecture and how we think it will help drive high-resolution printing forward into the future. Thank you.

And finally, we have a representative from Canon to talk about their directions and how they're getting involved with Mac OS X, Robert Shibata. Hi, I'm Robert Shibata. I'm a representative from Canon here today. And I just wanted to let you know that Canon is the largest printer manufacturer in the world.

And we are definitely behind Apple. As you know, we have a lot of products that are supporting the Apple platform. And actually going back in history, we've actually been working with Apple for well over 10 years, going back to the LaserWriters and the StyleWriters. And more recently, with products that are supporting the Apple platform, we have obviously printers, scanners, MFPs, a full line of products. Back at the keynote in January, Steve Jobs actually held up one of our USB-powered scanners and said something to the effect that, "Oh, this is a really neat old product," I think.

So, um... Actually, I did, I promised I wouldn't do too much sales type stuff here today, but I just wanted to show our, our little portable we have. So this is the BJC85, and it is actually the thinnest and lightest notebook product for the Apple platform. And as you can see, it's actually a perfect partner for a PowerBook. So those of you who may have PowerBooks or know somebody that has a PowerBook, you know, just keep this product in mind. And speaking about, speaking about miniaturization, we actually have the smallest MFP for the Apple platform, you know, in addition.

But not to talk about too much of our products, I didn't want to take too much of your time, is that we do have a full line of products. And we actually just shipped a photo printer, which is called the BJC8200, which actually has the smallest picoliter dot on the market.

And, um, Well, anyways, Anyways, just to say that our developers back in Japan have really been working very closely with, uh, with, uh, Paul Danbold and the printer team to really support the current operating system as well as going future with OSX10. So, um, OSX, excuse me. So, um, we really look forward to this new operating system with a lot of the power, the multi-functionality with this new operating system. So, thanks very much. Thank you. Just to let you know, operators are standing by. Thank you.

So as you can see, we've actually been working with three of the bigger companies out there. We have been working with other developers as well. And it's been a very interesting experience, because normally you think of the big companies out on the market as against each other and almost a cutthroat.

And it's an amazing experience to get all three of them in the same room and actually cooperating and giving us ideas on how we can make the operating system move forward. So we are very excited to be working with them, as well as working with other companies as well.

So, to wrap up the session and where you should be going forward, We first recommend that after this session, in addition to going to the sessions this afternoon, go back and take a look at the documentation. You'll find some documentation up on the website, developer.apple.com/techpubs/carbon/mult imediacarbonprintingmanager. Take a look at the documentation and get more in depth with it.

In addition, start using Carbon in your applications. As you're porting your applications to Carbon, use the Carbon printing APIs. And finally, we have an email address that you can send us feedback of your experiences, let us know what we're doing right, let us know what we're doing wrong. And that's at [email protected]