David Gelphman, former graphics and imaging engineer at Apple, talks to Guy and Rene about writing the book on Core Graphics, developing AirPrint, and discovers Montreal has bagels (Part 2 of 2).
Here's the audio, again, in case you missed it. And now, for the first time, here's the full transcript!
Debug 16.1: David Gelphman on Apple, Core Graphics, and AirPrint transcript
- Continued from part 1
Rene Ritchie: Previously on Debug with David Gelphman.
David Gelphman: Peter Grafanino, who was one of the next people that came over, he had been a graphics guy. Actually, he was the person that I remember people at Adobe working with, among others, on the next software. When they were doing display postscript. Peter, who I think is a super brilliant person. Basically, we had gotten an offer from Apple. Apple basically said, "Hey, we're not going to be able to continue to pay you contracting dollars. You're the number one contractor, dollar wise."
Saying to RBI, "We want you to come and work for us instead of work as contractors." That's what we ended up doing. Not everybody, but most everybody came to Apple as employees in June of 2000.
Rene: And now.
David: I quickly found an amazing group of people in the graphics team. There are the people that worked on the windows server 2D graphics. There is color sync which was integrated into quartz 2D. Quick Draw was part of that team, but Quick Draw was sort of just keep it going is what quick draw was at that point. Peter later acquired Quartz composer software pixel shocks which got integrated into macro OS.
He was the person behind the compositing windows server. I don't mean he was behind the code I mean the notion of having a Windows server and having it be a compositing windows server was a really daring move.
Guy: Amazing, so when they yanked displayed post script the thing that I did love was the compositing windows because that was a huge bet. I was writing video games at the time, and you can see how that was a bet on the way that GPUs accelerated texture blitters basically. We were going. Where you would render client-side into your texture and you'd upload the texture or just what changed in the texture and then be able to composite it on the curve. In 2000 that didn't really fully pan out.
David: Well, That wasn't the way it worked in 2000. It took a while before they really had it...
Guy: From having done GPU programming, I could see that this was the way it was going. This just makes total sense. I think that was a real good bet. It was one of those skate to where the puck is going sort of moments.
David: I absolutely agree with you, Guy. Absolutely. There was a lot of that. I really do. Peter was partly behind core animation which turned out to be a huge thing for both iOS and also on Mac OSX.
Guy: Core animation is kind of the next logical step from the composited Windows server, in a way.
David: Yeah. His team, he had 2D graphics on his team, 3D graphics, he had acquired a 3D graphics company that did GL graphics and brought them to the company. Prior to that, there was QuickDraw 3D. They got GL Graphics and QuickDraw 3D was deprecated pretty quickly. It was a pretty amazing technology and people. When I first arrived, it was really very different than working and, by the way, I worked with a lot of really smart people at RBI. It's just people at Apple is just another level, totally.
We came in because the printing teams, such as it was at the time, they needed help and they knew a lot about printing, so we basically ended up becoming a printing team over time. That's what I was doing primarily at Apple during my years at Apple. Because I was the graphics guy on the printing team for the most part, I did a lot of core graphics work.
When I look back over my career, you know, I sort of was thinking about talking with you guys and I look back at my career and it's like all of this sort of just came together right at the time that I started at Apple because I had this great background in PostScript, PDF imaging model.
Here we had basically that graphics system was the graphics system on the Mac. We got to build the printing system around that. The metafile format for the printing system instead of being PICT, which is what it had been in the old OS 9/8 days or whatever, was now PDF. Just making PDFs out of printing was like a standard part of printing.
Guy: Save As PDF is one of my favorite features, actually.
David: It is. There are some other things that got added over time. Rich came over to Apple at the time I did. He added this PDF workflow stuff where you can send your PDFs from the printing system off to other applications. Some of them are built in ones, like mail or whatever, but you can build a workflow where the PDF from the printing system gets sent to you and you can do something with it. That's pretty cool. I arrived at Apple and they needed help with stuff related to postscript generation for the new graphics system, which was the perfect fit for me.
Using CG immediately was just straight forward, partly because it's a great API, Derek Clegg, who is really pretty much the person responsible for that at Apple, really good API designer. It's a very clean, very well done API. I did a lot of code related to CG, that used CG internally, and some code for CG in the core graphic system. I thought, if you're interested, I'll tell you a little about how my book came about.
Guy: I was just going to say, you were the guy that wrote the book on the CG API just to set you up anyway.
David: I was actually pretty dissatisfied with the documentation at Adobe, sorry, too many As in here. That Apple was doing for the core graphics API, especially in the early 2000s. Coming out of a DTS world from Adobe, I come from a developer focused point of view, a lot. I looked at documentation. I'm like, "There's not enough."
Guy: It was standard to joke about it. What was it, description forthcoming, the most common description for method.
David: Do you feel like that's the case today?
Guy: No, they do a terrific job today. There are obviously spotty errors, but they do.
David: Nobody's perfect, but it's changed a lot. Part of that is just through Apple's success. They've put more focus on the documentation. I didn't feel like that was the case at that point. Really what happened is that coming over from outside Apple, a book that a third party was writing working with O'Reilly. They asked us at Apple to take a look at it and give some feedback on the book. Somebody gave it to me because I'm sort of a weenie in this way. I'd worked a lot with the documentation people at Apple, the printing docs and just in docs in general, also feedback on the core graphics documentation. I looked at what this person was doing with the book and I didn't like it. For me, it wasn't what I would like to see. I gave that feedback and I was just thinking, "Well why try and help somebody make a book that is the right book, why put all that effort in?"
Stupidly I thought, "Why not just write it?" I have to give just a tremendous amount of credit to the management at Apple for letting me do that.
Guy: It was really notable that a developer on a pretty important system was actually writing a book about it.
David: Is that the way it was perceived outside Apple? I had no idea.
Guy: To me it was. I didn't know that you worked there. It's uncommon for people to communicate in that way. It's not like you spill any beans, right?
David: No, no. That was carefully crafted to not do so. I can tell you a little bit about that if you're interested. It wasn't to write the inside story of how to use core graphics if you weren't using public API, it wasn't anything like that. It was how to use the public API. What was the imaging model? How to use the public API? How to solve specific problems that people have? For me, that's the way I looked at it.
Guy: The must have reference book.
David: Thank you.
Guy: I'm trying to plug it for everybody. Everybody go out and buy it.
David: I appreciate that. It's a little long in the tooth because it was published at the end of 2005.
Guy: The thing about the imaging model is still dead on.
David: All of that's still there, and they're still kind of useful. It has legs longer than maybe some books would. Obviously, if you were going to update it, there would be a lot of material. This was in 2005. This was right at the time that Intel based Macintoshes were hitting the market. It was well before the iPhone and iPad. It was a different world.
Guy: I mean so the particulars of using like a, whatever, like a CG layer may not be as important these days or have the same sort of effect, but the concepts are all still the same. You know what I mean? I think if you read that book and understand how this stuff works, then when you see new stuff you can understand how that works.
David: It's good you feel that way because that was certainly the goal of...I didn't want to write one of these books where you build a fake application. That's what that other book was, and I didn't like it. I like the idea of, "Here are the concepts, and here's some code. Here's how you write the code to do specific things," and the specific things are real-world tasks that people need to do like render to bits and then do something with those bits and that kind of stuff.
I do want to say something about Bunny and a little bit about how the book came about, because Bunny Laden, who's the co-author of the book with me. Bunny is somebody who I had worked with. She worked in the documentation group and was terrific, and I had worked with her on the printing documentation in that I was the person representing the printing team in terms of how the API worked and so on, and Bunny was working on drafts, or whatever. I worked with her.
She was and is unbelievable in terms of both her writing skill and just how great she is to work with. I would make all kinds of comments about stuff that I didn't like about some piece of documentation she'd done, and I wasn't mean about it. I just, "This wasn't right or this..." whatever.
And there are some people who get defensive about that, and Bunny is not all that way. She'd just take it great. This is great information. She'd turn it, and was great. And so when I had the chance to work with her on the book it's the only way that I would actually work to do that book was to do it with her.
Now what ended up happening -- and I did -- but what ended up happening is I had somehow imagined this process would be like I would work with her on how what was going to be in the chapter, and so on and so forth, but I thought she was going to do most of the writing, because she was the writer.
But she didn't get the permission from her management to spend the kind of time on that book that I did. I got to spend a lot of time on that book, at least three-quarters of my time during the period of time I was working on it.
Guy: That's great.
David: I had a really great management chain.
Guy: Yes.
David: I was really lucky, you know? Let's just say it's the inverse from the experience I had working at Adobe where the management changed maybe wasn't as easy to come up with a solution like that. Peter Graffagnino and Rich Blanchard, who was my manager at the time, they were like, "Yeah, do it. This is great." I wrote most of the text in that book, and Bunny, who was just critical for sort of organizing things better than I could organize them, really great ideas about some things to put in or take out, or whatever. Once I wrote the prose to turn it into something better than it was when I wrote it. But I ended up writing a lot more than I expected to, to be honest. If I'd known what it was going to take to do that book beforehand I might not have taken it on, because it was a lot, a lot of work.
But it was really satisfying. I mean it was really satisfying. The UPS guy pulls up, or FedEx. FedEx brings the first copy of the book from the publisher, the first from the print run, and that was an amazing experience to have that in my hands, because I thought they'd done a brilliant job of making it look nice and just to have that after all that work, because it took a while.
Guy: It must be satisfying. It's like after writing software for so many years, having something physical in your hand that you're...
David: It was really different. A lot of people are involved in the final product for the book, because there's printing, and there's formatting. We didn't give them camera-ready anything. They did the design and all of that. But it's much closer to, OS, Snow Leopard comes out, you have a piece of that, but this book came out I had just an enormous piece of it that was just me. I was very pleased with it, and I got very good feedback. I still get some nice comments from people about it, "Well, it was an expensive book. I waited to buy it. I don't know why I waited to buy it." Now they got it. How much it cost that had nothing to do with me.
I do have a little story about how my name ended up being on that book, because it wasn't going to be. Bunny and I, when we started that book, that book was going to be author, Apple.
Guy: Oh, really?
David: It wasn't going to be out on Amazon.
Guy: Interesting.
David: We knew that, when Steve came back to Apple that was the policy. It was the same policy for the software, that there were no names on programs within OS. All that stuff went away. That's fine. I mean I wasn't writing the book for people to know my name. I was writing the book because I wanted third-parties to know how to program Quartz. And well, not just third-parties, people within Apple, too, but that's another matter [laughs] .
What happened is we got down to the very, very end, we're all done, everything's turned in, all the artwork had been approved - we thought - and I thought we were all done. Then I guess they needed to have product marketing sign off on the cover.
Now the cover design for that book it's got a crystal on it, which we had gone through a lot of different ideas for the cover, whatever. Morgan Kaufmann, the publisher, had come up with this, what I thought it was a really cool-looking graphic of a crystal, so quartz that seemed like that sort of fit.
Guy: Do you know where that code name came from? I've never understood that.
David: That's a good question. I don't know.
Guy: I've got to find out.
David: I might be able to.
Guy: Yes. Somebody write in and tell me where Quartz came from. Anyway, sorry, go ahead.
David: I'd be curious. I know some people I could ask. I've never actually asked that question. Internally it probably was a product marketing thing, because internally it was known as Core Graphics. All these things had the internal name, and then they decided to call it Quartz. I don't know where that came from. It was already called that when I got to Apple. We're at the end of the line. I mean I'm just like, "Oh, thank god we're all done. This is a big, long project." And somebody in the product marketing group sent an email out, and they were complaining. They said, "What is that turkey drumstick graphic that you're talking about using for the cover?"
I'm like, "Oh, god." And this is somebody that I'd some involvement with before who had never been helpful. And it just set off this whole, "We can't have it." Now all of a sudden the people in product marketing got involved, because, "We can't have Apple's name associated with this thing that's not a perfect graphic." It was that kind of thing.
Guy: I guess.
David: And you can imagine when the publisher's trying to meet their deadline for publishing it and for me after all this work, and Bunny, a lot of people, and we had thought we had had all this permission worked out. Anyway, the solution ended up being somebody, I assumed it was Bertrand Serlet, went to Steve and said, "Here is this problem. Can we put the names of the people who wrote the book on the cover? So that it doesn't have to say it was authored by Apple"? That was the solution, and the answer was OK.
Sorry, bad choice of letters there, I guess [laughs] . But the answer was yes. I was thrilled of course to have my name on it. That that turned out to be the solution to this intractable problem was fine with me and Bunny. Both of us were perfectly fine. To me, it was funny. It wasn't funny during the process. I'll say that.
Guy: Yeah, I'm sure.
David: [laughs] It was funny by the time we got to the point of our names are going to be on this. Totally unexpected [inaudible 19:01] .
Guy: It's like the inverted credit system.
David: [laughs] We don't like the graphic for the front, so put the authors' names on it. Let them be responsible for that [laughs] .
Guy: That's awesome.
David: I don't want to say the right thing happened in the end. I don't know.
Guy: No. If you're writing a book, and it's not being published by Apple, it's totally fair to put your name on it as the author.
David: But it was never published by Apple. It was published by Morgan Kaufmann.
Guy: That's what I mean. [inaudible 19:33] press. The thing, at one point, it used [inaudible 19:35] .
David: No, it's not. They used to have a press. This was not an Apple press thing. That's long gone.
Guy: If you're going out to the Apple press, fine, Apple. If you're not, it's unfair.
David: This had happened before with other people where they are writing books internal to Apple, and they didn't get their names on it. Some people were unhappy about that. I can understand that. I just knew going in that we weren't going to have our names on it.
Guy: I think that's it. Once you know going in, you signed up for it.
David: That's exactly right. I had signed up for it. That's OK. I felt very gratified to have my name on it. When I got one in my hands, I thought they did a beautiful job of printing it. But Apple owns it all. This isn't something I get royalties for. It's Apple's book. If I wanted to do a revision of it, I would have to work that out with Apple.
We've been asked by the publisher, "Did we want to do a revision"? Because it's older, there's a lot of good stuff you could put in it now. The world's changed. There are so much more information now out there about Apple, about the graphic system. Other people are doing some really fine work.
It's a major project to update that book. I don't think that's coming anytime soon. I don't think I'm likely to do that. But I'm glad that it still has a lot of utility.
Guy: It's a terrific introduction to the, what I can't stop calling, the postscript imaging model. Is there a better name for that? PDF?
David: The reason people refer to it as a PDF imaging model is because it's evolved. It now has compositing operations built in, not the kinds of compositing that NeXT built into to add to display postscript, but different ways blending graphics. It has blend modes now. That's not something that ever got added to postscript. That actually adds quite a lot of computational difficulty to rendering the graphics. It has added another layer of sophistication. Let's put it that way.
Guy: From now on, I should call it PDF imaging model? That's your...
David: I tend to say postscript, but I'm an old...
Guy: School.
David: It's postscript PDF. The basics of the imaging model are still postscript.
Guy: To me, it's that whole thing: The origin's in the lower left corner.
David: Yeah, all of that.
Guy: You draw from the middle of a pixel. Man, you must remember when OS X shipped, everybody was going aped because they had to draw on the middle of a pixel to get a one pixel thick line. Now with the retina screen, guess what? It's working pretty good for you now, isn't it?
David: The real thing is at this dimension, in the early 2000s, this is some that Peter was trying to pursue, I was so, so excited about the idea of high DPI displays. I really thought, "God, we are missing the boat. We have this great imaging model. If we can push the displays to higher resolution, it's going to be a big selling point for Macintosh." I really wanted to see that effort succeed. Really what happened is just the hardware wasn't there. Maybe it's going to be expensive for the displays. Maybe the displays were but the GPU hardware...The stuff wasn't to the level that it needed to be to get that performance. It wasn't the big focus. Now, retina graphics is like, "Oh, my God." You use it on iPad, or you use a...
Guy: That's a jackpot.
David: It's just the quality that's so fabulous. They found a good way to do it, to not make all the developers to suffer greatly which would have been the case if, instead of having 2X scale factor, if you add the possibility of 1X or...
Guy: 1.5 or whatever.
David: Exactly.
Guy: I like the idea of that, but it felt like it was never going to work.
David: That's exactly right. I really want to see this, but everybody was going to have to rework. Nothing is going to look good unless you ran it 2X. It just wasn't going to look good. There are too many difficult things. If you look in the book, I had some stuff about that because I was anticipating that we were going to do this. In core graphics, there were routines. I wrote some about it in the book. Sometimes you had to this in your postscript code if you wanted some of the graphics...
Guy: To figure out the width of a single line, you have to do a bit of...
David: Not just that. If you wanted to land your graphic and if you wanted to land your pen at the right place in the pixel in user space, you have to calculate it in the device space, and then transform it back into user space. It was that kind of stuff, and they put in some functions in core graphics to let you do that. There's a little bit of code in the book about how to do it. But it was going to be a lot of work for developers. It's pretty much for free for most people. Yes, there are developers who were doing some things where they were doing some maybe pre-rendering off-screen.
Guy: Yeah, I had a bunch of issues with an app.
David: But people had figured it out pretty quickly.
Guy: Also having two modes makes it a lot nicer, like you don't have to figure out anything in between. One thing that is funky is having screens like one screen at 2X and one screen at 1X. That gets a little crazy. Well, math works it out.
David: Some of that, like with color management, that was another kind of thing because there's a lot of stuff in core graphics to let you draw using color managed workflow. Guess what? Your display color space maybe different between the two displays you've got. If you really wanted to do some careful work, you might have to take that into account. Hopefully not, hopefully, you're drawing in a calibrated space, and all the math is done for you. But people do a lot of things which aren't, and you can end up with some surprises.
Guy: It's a very difficult problem space to solve elegantly. Mostly it's done really, really well on OS X and iOS.
David: In iOS, you have the benefit of not having a second display [laughs] .
Guy: Exactly. I don't just mean the color space.
David: You mean the general problem?
Guy: I mean the general problem, like an imaging problem, is difficult. It got nailed really well on OS X originally. It scaled to the point that you can take that similar approach and stick it on the iPhone one. The way that it renders on the host into texture and then composite stall was just really forward looking and very smart step to take.
David: The technologies that got built into the OS in the early stages of OS X absolutely led to what was possible on the iPhone.
Guy: Yeah, except it led to most of the complaints, right? It was just like resizing a window just takes forever. It's like, "OK, just wait for it. Just give it a few years. I know it's going to be painful, but this is the right thing to do."
David: Also, people figured out some optimizations. People did figure out some of the library side stuff. Some people figured out better ways to do it. But you're right, the hardware got a lot better. Don't you think that if you design for today's hardware, then that maybe is the mistake? It was incredibly optimistic. Peter was an optimist. That's for sure.
Guy: I don't know if he's optimistic. It seemed like just the right thing to do. But I was doing a lot of GPU stuffs, so I could really tell what the intent was.
David: Let's just say that an awful lot of developers weren't. That was not an obvious thing at the time.
Guy: That's true. So it's the most recent thing you work on an Apple, before you left with AirPrint?
David: Yeah.
Guy: I thought it's interesting. I was surprised that you guys even brought printing to iOS for some reason. I don't know why. It seems so obvious now. What was the impetus at the time behind that?
David: Behind bringing printing or behind AirPrint as a printing solution?
Guy: I guess both. Once you decide to do printing, maybe AirPrint falls out naturally from that. Does that makes sense?
David: I would agree with you, but I wouldn't say that was necessarily what everybody thought when we were first starting work on it.
Guy: OK.
David: [laughs] I mean in this point in time, it seems pretty obvious. Man 1 I don't mean to diminish the...
David: No, no, no. I know you don't, Guy. I just think you're right. It's just that some people have to agree. The first thing is, "Why printing"? That is harder to answer. To me, if you want these devices to have rich capabilities, that is one that is pretty much given. There are some things that are missing that should be given that aren't there like create PDF out of printing thing you have on OS X. But being able to print for a lot of people is really...
Guy: A mass market feature.
David: It really is. By the way, I know this is jumping ahead a little bit, but I'll just tell you, for me, if my wife wants to print a photo, I'll say, "Get it on your iPad and print it from there." It's just so darn easy. I've got 4x6 paper loaded in the printer here. She just prints, and she get a really nice...It works that really good.
Guy: I know a lot of people who [inaudible 30:37] now, and anyone in the family wants to print.
David: To me, in part is the failing of OS10 printing, because iPhoto printing is way more complicated than it really needs to be for the common person. Personally, look I am coming from a printing background. I take it for granted that you want printing on a computing platform, which the iPhone and iPad are computing platforms. It's just they are disguised very nicely. When we tackled the problem of how to do printing on the iPad and iPhone, or iOS, basically, the question is on a Mac you don't even see it anymore because of the way drivers are delivered. They are all downloaded now. Historically, we shipped gigabytes of drivers on the OS platform.
Guy: Abnormally so. [laughs] I was so angry at how many gigabytes I had to get for that. It was an option. Right? It was like, "No. Don't install drivers for that thing."
David: Yeah. Sometimes you could choose which manufacturers. There are all kinds of different scenarios. I tried to stay as far away from those things in printing as possible. Having third-party code run, as part of the OS, as opposed to as a third-party app, was something that was not really going to happen on iOS. It just wasn't.
Then you have the problem of how do you support any decent number of printers. Even if you said, "OK. We're going to only support the printers from manufacturers XYZ, the big three, Epson, and Canon, and HP. Even among their printer lines they had tons of different drivers for OS10 just for their printers.
That just wasn't feasible. We on the team thought that the only way to do it was really to say, "OK. We're going to define how printing is going to work from the point-of-view of the printer, not from the point-of-view of the user." We'd had a lot to do with that, too, but AirPrint means two different things. I'll just say a little bit about it.
AirPrint, it's a technology that Apple defined that we licensed. They, now I don't work for Apple anymore, but Apple licenses to printer manufacturers. Basically, you build this technology into your printer, and then you're an AirPrint printer, and anything that can print to an AirPrint printer can print to your printer.
The idea was to have a communication protocol that defined how you are going to talk. It's up over Bon Jour for discovery, and IPP which was called the Internet Printing Protocol, which is basically a control protocol for how you communicate the data to the printer, and commands for what the printer is supposed to do. I don't mean the graphics that the printer is supposed to draw, but I mean you are supposed to print on this size letter paper, or this kind of paper, letter, A4, whatever.
These features you are trying to turn on in the printer, quality modes, and things like that. There is that layer, and then there was the PDL layer where JPEG is one of the graphics formats that you can send to the printer, because clearly when you are printing photos you want to be able to ship off the JPEG, if you can.
PDF is one of the protocols that you can send PDF documents to printers that support it. That's not a requirement for an AirPrint printer, but that's one of the things. There was a Raster Graphics format that Apple defined that everybody had to support.
Guy: Is that a fixed-pixel definition?
David: Yeah. Well, there is a couple of different. It's basically a Raster format with a couple of bit depths that are potentially supported, and a couple of color models that are supported, and compression scheme, and stuff. No. It's pixels. If you are going to do vectors, you're going to do PDL. Basically, we had to get buy-in from Apple Management to say, "Yes. We could build into iOS a printing system for which maybe there aren't very many printers when it first ships, because we're basically defining a new printer language," if you want to call it that.
It was the only real practical way to define a way for iOS to print, and it's turned out to be very successful. There are now a lot of printers from tons of manufacturers, including some you wouldn't expect. Like Dell, for example, ships some AirPrint printers. Almost all of HP's product line now, Canon, Epson, Brother, all these printer manufacturers, now they are doing AirPrint, which is great.
The idea was you buy a printer you don't have to think about whether it has this AirPrint or not. It just does.
Guy: It seems to me that this is the way it should have worked always.
David: There are those of us who feel that way. [laughs]
Guy: Yeah. Fair enough.
David: Well, I agree with you. You know what? We learned a lot.
Guy: Yeah.
David: We learned a lot in 20, 25, 30 years. In some ways, Post Script was some of these things. Post Script was sort of part of that, but it didn't have the control language. Well, I'm calling it a control language, but the things that IPP allows. Any feature support in Post Script was done through the Post Script language. It was connected to the PDL, which has some really negative effects.
Guy: PDL is Printer Document Layer, is that it?
David: Printer Description Language, I guess. No. PDL, I guess, is Printer Description Layer.
Guy: The stuff you are going to print, basically.
David: Well, it's like Post Script is to PDL, PDF can be. It's a PDL for AirPrint.
Guy: Yeah.
David: Yeah. Sorry. You know how it is when you get used to these terms, and you forget.
Guy: No. I knew what it was. I just don't remember what it expands to in anyway. [laughs]
David: Yeah. No. We learned a lot over time, and IPP didn't just show up for AirPrint. It was something that had been developed over a long period of time. Mike Sweet, who is now at Apple, has been at Apple for years now, but he is Chair of the IPP. It's an international standard. He has been formative in the development of it over time. Early days of OS10, we licensed software from Mike whose company, Easy Software, he did the software called CUPS, and we licensed it, and that became the server part of the OS10 printing system.
Guy: Common UNIX Printing Service, yeah.
David: I don't know if it's Service. That sounds good.
Guy: System?
David: I thought it was System, but it could be either one. Mike will yell at me later, now.
Guy: Yeah. Now, you know what? Now, I'm sure it's System. [laughter]
That gets built into OS10.3 or something like that. Does it switch over to it?
David: 10.2. We shipped CUPS, and that's what enable printer sharing, for example. CUPS was an implementation, but the actual language, so to speak, EP, that was the key part. That was the part that every printer vendor that was doing an AirPrint printer now had to build IPP into their printer. It's been a huge win. There is a lot more that Apple can do with AirPrint. That's the printer side of it. The other side it was the iOS, or the Mac side where we had to build client support in. To people on iOS, AirPrint is the printing system on the client side, too. If you look at the APIs, people look at that as AirPrint.
Guy: It's a mixed bag. What it enables is pretty interesting, because you can get feedback from the printer. The printer could tell you what kind of paper is in there, and then the client, being the iOS device, can format specifically for that paper.
David: Yeah. One thing that was a really important part of building a simple-to-use printing system on iOS was there is not a lot of UI, and the idea was to build as much intelligence into the printing system itself so that the user didn't need a lot of UI in order to print. If we know what size paper is in the printer, then we can communicate that to the app, and the app can format for that size paper, and the user doesn't have to choose a size paper. Where there is multiple choices, for example, and this is already in iOS, there is multiple photo papers in your printer, then an app that is printing photos will give you a choice.
You can choose which photo paper you want to print on.
Guy: That's cool.
David: Yeah. It is cool.
Guy: I didn't know that. [laughs]
David: Yeah. It's a relatively new thing. It's part of IPP. It's part of what is in AirPrint. It's something either you have to be able to configure the printer to tell us, or there has to be a sensor in the hardware to know what type paper, and that tends to be a more expensive solution. At least if you can configure your printer to tell it what paper you've put in it, then it can report to the host. Geez, I don't want to have to pick a paper size. Just print on what's in there. [laughs]
There is a lot of that. We tried to make the iOS printing system pretty smart in that regard, and AirPrint is a piece of that trying to be smart.
Guy: Well, it's a second shot at doing what the OS10 printing system. Right?
David: Yeah. Of course, we support AirPrint printers on OS10, too. That's something we have there, too. Ideally, you can plug in your printer and you don't have to download any software at all. It just works. That's the way I run here at home. We run the AirPrint printers in the house.
Guy: Yeah. I do the same. Not that I print that often.
David: Me nether. One thing I just wanted to say is I feel like my career and working on printing systems and stuff, I feel like I just happened to be at the right place at the right time, because my personal opinion is I'd like to phase out printing. I don't want to see a lot of pieces of paper. Adding "save as PDF," I hope that has, already, in OS10 saved millions and millions of trees sending that to somebody instead of printing something and mailing it, or whatever.
Guy: I do that all the time. Safari has that nice feature "save as web receipt." There is a bunch of apps.
David: That's not Safari, by the way.
Guy: It's the printing system.
David: It's the printing system. Safari can do it. That's what you're using, but that's a just a piece of the printing system.
Guy: Yeah. No. I agree. I just meant they have a menu item for it, and I'm sure it's like three lines of code.
David: I'll tell Rich you said that. He'll be glad to hear it was only three lines. That's exactly it. I would like to see that in iOS as well. Not that specific thing, but the ability to get PDF out instead of pieces of paper. I don't know. I felt like in terms of leaving Apple, I am personally hoping that printing becomes less important. It has over time. I don't mean that because I've left Apple. The time has been coming for a long time, and hopefully it can build out more, if necessary, to make it less necessary to print. My wife still prints all kinds of stuff.
Guy: Yeah. It's still a common thing, but it's one of those things that you hope like 15 years from now is not common.
Rene: For generations of people they want to hold it in their hand, or it's not real.
David: Sorry. The first developer conference I went to was in 1987, and what was going on at the time was Mac2 had just come out. The Mac SE had just come out. Steve was long gone. I've pretty much been to every developer's conference since. This is probably going to be the first year I'm not going. [laughs]
Guy: That's good.
David: Yeah. First of all, you guys on the East Coast have a big advantage. [laughs] Did you go last year?
Guy: Yeah. I did. I don't know. I got lucky.
Rene: Likewise.
David: Did you actually have a ticket, Rene?
Rene: I did.
David: You did. I used to go. For my first, I'd say about seven years at Apple, I used to go and I'd spend the week. Well, when it was in San Jose I could come from Santa Cruz, and I'd just drive over. When they moved it to San Francisco, I would go up and I'd spend the week in San Francisco, and I would go like anybody would go. It was plenty busy at the developer's conference, but I could still do that as an employee. Not every employee could do this. I really did try and have a developer focus as much as I could. It was one way to learn about stuff you're not working on. It's hard to find time to learn about all that other stuff when you are doing development in the company.
I loved the developer's conferences. Over time they got so crowded. There was so much stuff. As employees, we pretty much the only part that we got to go to was if you were presenting, or it was your team was giving a talk, and then we had these labs, which I loved the labs. I don't know if you guys tended to go to them?
Rene: Sure.
Guy: Yeah. I've been to a few. There is a lot of value in those labs.
David: I really liked it. People would come and you'd get to talk one-on-one, and they had a problem which usually you could solve pretty quickly for them, which was nice. There are some that are a lot more in depth. There are some you can't solve, but I liked talking with the developers that came. I went to an awful lot of the conferences. Then, I'd say about the past maybe four years or so, it was pretty much you couldn't go. You just couldn't go as an employee.
There is one thing here that I wanted to mention, and by the way, whether you guys want to use it or not, but I just think it was sort of funny. I did listen to your podcast with Grant Paul, which I thought was really interesting. I don't know the guy, but just to hear him talking about the jailbreaks. One of the things that I remember was the early days of debuggers and stuff on the Mac, because in `85 timeframe, or `84, `85, or whatever.
You started with the two-Mac debugger, which basically you had a Mac over here, and you had another Mac over there, and one of the Macs was basically showing all your debug stuff while you are debugging your app, and it was all your debugging machine code, and all of that.
Then this really cool debugger came along called TMON. You ever heard of this?
Guy: No.
David: Yeah. This is a long time ago. The TMON, all of a sudden, what you could do with the two-Mac debugger you could do on a single Mac. It's like you could drop into TMON, and it was like a-I don't want to say Windowing System. They had a funky way of doing Windows-but it was really cool. When I think back on what those things were like, machine code debugging only, no Windows, really. Just Window constructs and stuff, and I just thought, "God. We had it so tough." Yeah. Listen to this. [laughs] Listen to what this guy Grant is talking about with compiling his stuff on an iPhone, and debugging it.
Guy: Yeah. [laughs]
David: Then he's talking about I forget which game console.
Guy: It was Nintendo Wii. He was saying you just break it.
David: Never again. [laughs] You have to buy a new one. Well, he figured out how to fix that. He figured out how to make it so this couldn't happen. You could revert. I hear that and I am like, "Oh, my God." I guess this is always true. It's always there is going to be some low-level, crazy thing you have to do if you want to do some neat thing. I just thought that was just so cool what these guys are doing. It's like you want to say, "Oh, we had it tougher in the old days," and then I'm going, "Well, you know what? These guys they did a lot."
Guy: They got it pretty tough, too. Yeah. Exactly. Remember when Macs used to ship with a debug button?
David: That's what I'm talking about. That's exactly what I'm talking about.
Guy: OK.
David: A programmer switch you would put on the side of your Mac, and you'd hit the switch, and it would drop into the debugger, and you'd look at whatever. [laughs]
Guy: I've had to do that before, but I think I got my first Mac in `95, `96, something like that. I didn't know what it was called. I was just like, "There is a programmer switch," and I thought that was pretty cool. [laughs] Not that I had ever used it for much, but I thought it was cool.
David: Oh, no. You had to install it on the side. You could reboot with it, but it had two buttons. The front one was the reboot, and the back one was to drop in debugger. Yeah.
Guy: Very cool. Crazy, but cool. [laughs]
David: Really early on, when the Mac first came out there was no Internet. There was email. How you got information about stuff, and how you communicated with other developers was-not just developers, the Mac community-you waited for "Mac World Magazine" to come out, the next issue of "Mac World." I remember drooling waiting for that next issue of "Mac World." The ability to communicate with other people who are interested in Macintosh, it was pretty much users groups. I used to go to the Stanford Users Group. Being around Apple, they'd get some pretty good people. I remember Bill Atkinson was the one I was particularly interested in, because he was talking about QuickDraw, talking about Mac Pane.
One thing that was really cool, and that played a huge role in my interest and ability to get booted into this community was a guy named Gus Hernandez, who I found out now works at Google. Gus started a little developer group that was a little subgroup of the Stanford Users Group. If you were interested in development, you could come to that.
He got this parade of superstar people to come and talk. Andy Herzfeld was obviously the big name that you would recognize, but Bruce Horn, who was coauthor of "The Finder," Bill Budge who had been a superstar Apple II guy, Larry Canyon who done the disk driver stuff for the Mac, maybe for the Apple II, Chris Crawford who was a game developer early on. I don't remember the name of the program anymore.
Guy: I don't either.
David: He did a cool game. I just remember that.
Guy: I was such a fan of that guy coming up.
David: Is that right?
Guy: Yeah, I'm stuck on his title. It was one of those guys that I was like, "Man, I want to do what that guy does."
David: These guys came, and you can imagine the developer group wasn't a huge group that came. It's not like the user group where you'd get 100s of people, or 100 or more people. This was a handful of people, 20 people maybe, at the most. Gus managed, I don't know how he did it, he managed to get these superstar people from Apple, or in the community, to come and talk to us. It really was so much fun to sort of touch that and to hear these guys talk. Of course, they were sort of like gods at the time. I knew nothing about any of this stuff. When the Mac first came out, somebody at Stanford first started this mailing list, which was sort of a new thing, at the time.
This was '84. An awful lot of people didn't even have email. I had email because I was at Stanford. If you were at a university, you probably did.
Guy: It was still a UUCP style, right?
David: Yeah. Exactly. I was at SLAC so we had a thing called BitNet that somehow connected us to the rest of everybody. You had to know what network people were on. It was really pretty weird. But, somebody started a mailing list at Stanford. Basically, people would send in their information and it would get compiled into a big digest and it would get sent out. It was called the InfoMac Digest. I met a lot of people through that. At one point, I was moderator for that. That just meant you just took mail messages that came in and you used emacs to paste them together and send them. I'm not kidding. That's how I learned emacs. You pasted it together into the digest, and you mailed it out to this mailing list of I don't know how many hundreds of people that wanted to get it every day.
I met a ton of people through that, including some people who later on I ended up working with at Apple or other companies. Like Darren Adler, who I know Don Melton was talking a lot about. Darren, super brilliant guy, I worked with him at General Magic. I didn't work with him at Apple, per say, before he and I were both at Apple at the same time. I met a lot of people through that.
We used to organize these things called Netter's Dinner's. When Macworld came around, which was a big, giant thing at the time, we'd all try and get together to have dinner, so that all these people who you didn't know, but you met finally at some physical location. We went out to Hunan restaurant, a big group of people and stuff.
That was the connection to the community. It's so different now and I love it now. It's so much more connected. What we did was so primitive compared to it. It was really formative, made a difference in my life.
Guy English: There's still that huge bonus of actually getting to meet people and...
David: Totally. No that's why [inaudible 54:53]
Guy: Do this kind of thing. Like chatting and...
David: Absolutely.
Guy: Shooting the breeze.
David: That's why I said at the beginning. When we first sort of started Skype doesn't work man. When it does, look what it lets you do. Rene, you're in New York right now?
Rene: Yes.
David: Guy, you're in Montreal?
Guy: Yes.
Rene: He is getting much better bagels than I am right now.
David: What?
Guy: Don't, you're going to start a fight.
Rene: Montreal's know for its...
David: They have bagels in Montreal?
Guy: Yeah. Exactly.
David: That can't be?
Guy: You came down on the right side of that fight.
David: Wait, better bagels in Montreal? I can't believe that.
Guy: I will send you some sir.
David: Are you serious?
Guy: Yes. Montreal bagels are awesome. There's places in New York that have people drive up here to buy bagels and bring them in the morning.
David: I'm not editing this part out either. [laughter]
Guy: It's all bagels. All the time. This is it. This is actually how we're going to lead into the show. It's bagel time.
David: OK. That's fine with me. I'm really impressed. I did not know that. Many people came back from Singleton Conference and said wonderful, wonderful, things about Montreal. I've never been to Montreal. But I heard that and I'm like, "Wow." This must be an amazing place. But when you add bagels in, now you're talking.
Guy: Well we'll have to find things to get you out here.
David: That wouldn't be very hard to do. The bagels wouldn't even be necessary. [laughter]
I went to college on the East Coast, and I had to go to New York some. Those were the gold standard bagels. I'd lived in Dallas as a teenager. In college years I went home to Dallas during the summer. I worked at a place that was like a chain that was coming out of New York called the "Bagel Nosh".
They made pretty good bagels. They made water bagels. I thought, "OK. This is as good as you're going to get outside of New York City. When you come out here to California, forget it. Don't bother. If you have bothered, I'm sorry. If you haven't, don't."
[laughter]
Guy: We'll take care of you on the bagel side. [laughter]
Joking aside, there are New York bagels, there are Montreal bagels, and then there's just everything else that doesn't count.
Rene: Yeah, there are Montreal bagels, and then there are New York bagels, and then there's everything else.
