David Gelphman on Adobe, PostScript, and General Magic

David Gelphman, former graphics and imaging engineer at Apple, talks to Guy and Rene about working on Postscript at Adobe, his time at General Magic, and how to avoid inverting bug fix prognostication equations. (Part 1 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: David Gelphman from Adobe to General Magic transcript

David Gelphman: If you could've found this all out on the Internet, I would've been fascinated.

Guy English: I actually went back, and not to say that I didn't fact check you... [laughter]

Guy: ...but I went back to find a bit of context. [crosstalk]

David: No, it's crack up. I understand.

Guy: Like some of it's hard to find, you know.

David: So much of this happened before the Web. There, actually, is some old stuff that you can find, that's true.

Guy: I was so happy, when I got this, too, because it had been bugging me and I hadn't gone and figured it out. I think I was talking to Gruber on his show, at one point, and I was trying to name companies that span out of Apple, or interesting Palm-style...

David: The General Magic stuff?

Guy: General Magic, exactly. That was exactly the one I was trying to think of and I ended up saying Handspring or something.

David: That came out of Palm, too. The Palm got us a job.

Guy: It was General Magic with Magic Cap. We're getting ahead of ourselves.

Rene Ritchie: Today we are talking to David Gelphman, how are you David?

David: Oh, I'm fine.

Rene: That's the best answer ever.

David: What would you like? Is there multiple options? I didn't see anything. Doing well.

Rene: You got a lot of attention recently for a blog post. I'm going to rewind heavily before that and just ask you. You have a rather storied career. How did you get on the path to doing what you do now?

David: You really want me to start sort of early on? Really early on?

Rene: Yeah. What introduced you into computing and maybe graphics? Everything that you ended up working on.

David: It's sort of interesting because I graduated high school in 1975. In that time frame, the only thing I knew about computing was at my school they had one class in computers. I didn't get the chance to take it because it conflicted with a class in AP chemistry which I wanted to take my senior year. I didn't get to do any computer stuff really in high school at all, except, and this was a funny thing when I thought back on it, one of the kids that I was friends with at study hall used to bring his dad's HP65 calculator.

Which was this early, I don't know if you've even heard of it, it was the first programmable calculator.

Guy: It was Reverse Polish Notation, right?

David: HP, all their calculators were RPN which I loved. This thing was programmable. It wasn't just a calculator. You could actually store programs in it and stuff. It had a little card reader that you could both read programs and you could write out the programs that you'd written on the card reader so you could read them in later. So, that was actually my first and only programming experience until I went to college. The kinds of programs that you would write for something like that didn't have any graphics or anything like that, but it was just pure calculation kinds of things. You could enter some input, press a button and it would calculate some result that you could program the steps for.

So, that was sort of programming in 1975. At least, as far as I knew. Then when I went to college, I was a physics major in college and I actually did do a little bit of computer stuff, but nothing formal in the college classes or anything like that. All the classes for programming were in the electrical engineering department at that time.

But I had calculation kind of programs that I did for one of my professors. I did some work for him. It was all enter stuff on punch cards and send it over to the computing center. Then pick up your printout later on.

It was always computational kind of stuff which was really Fortran. That was the language of science at that time. The only other language I'd heard of was assembly. I actually did a little teeny bit in that, but that was a total different kind of animal and didn't fit anything that I needed to do.

Guy: Fortran is interesting because it is still kind of low-ish level language.

David: You know, if I remembered any of it, I might be able to comment.

Guy: It exposes some weird stuff. I think everything's passed by reference?

David: Yeah, that is one thing that was pretty interesting to me when I started learning a language like C. I just remember in the kind of computing that we did, we had like a common block which, I guess, was a structure of some sort. When you passed it to a sub routine, basically a sub routine can change anything in that. When I actually started doing anything with C, I'm like, "Wow. You mean all these variables are local and if I make a change to it, the next time I call the sub routine the data is not what it was the last...?"

I mean, it was really weird to me because I'd just grown up with this other way. Now I think about it using static variables is something you generally avoid unless you have some real specific reason for it. But, yeah, that's exactly the way Fortran was.

Column 6 was, I guess, a continuation column.

Guy: Oh, yeah.

David: I mean, honestly, the last Fortran I did was probably 1984, 1985 or something like that.

Guy: Yeah, I remember -- I think I had to use it in one class one time and COBOL, too, at some point.

David: I never learned any of that. That was a business thing, so I just didn't do business.

Guy: Good for you. [crosstalk]

David: Well, I just -- that's the way I thought of it at the time. I was like, "What?" Really, that was true. After college, I went to grad school at Stanford. It was the same kind of thing. All of the programming that I did was in support of doing calculations or data analysis. That kind of thing or monitoring equipment that we were using to take experimental data.

I didn't have any interest in the personal computers of the day. I would put it a different way. I didn't really know anything other than when the IBM PC came out.

I had no interest in that at all. It was just more kind of computing as far as I was concerned, of the same kind. I mean, I just didn't know why you'd be interested in such a thing.

That really all changed for me in 1984, because I was really lucky. I had actually been away when the Mac was introduced. I was in Germany for the experiment that I was working on.

When I got back -- soon after I got back -- I found out that one of my colleagues at Slack had a friend at Apple. I had heard of Apple. He had a friend at Apple who had showed him the Mac, and he was just raving about how cool this thing was.

He was nice enough to come back up to Slack and give us a little demo. I was just floored, because this was so unlike anything I had ever imagined or seen. It wasn't a kind of computing. Obviously, it was not the kind of computing that I was familiar with previously. It was something really interesting.

The graphics, obviously, was a big part of it, but the whole thing, to me seemed just completely magical. I had no idea how this could possibly work. Just with my background, it didn't make any sense.

Guy: Right. Because the interactivity of it is totally alien to somebody who writes a giant experiment and has a computer crunch on it for a day and a half kind of thing.

David: Well, yeah, we had dedicated systems and stuff. But basically, there was no interactivity for anything that we did. Plus there was no graphics like that. I mean, the kind of graphics that I was doing then were plotting data. You'd have charts and graphs and that kind of thing, but nothing like what you could see with Mac Paint. When I was working on my dissertation, I was using Tech, which is still an amazing tool, but it was not any kind of WYSIWYG at all.

Even previewing your text stuff came pretty late in my graduate career, where you'd run your text stuff through a processor and then you could see it graphically on some other display. That was a way cool thing, but it wasn't like you'd interactively edit it.

Seeing the Mac just totally changed my interest in computers and doing computing. It was like I was really drawn to that.

Guy: So you started to -- you put aside the heavy duty physics computing and you got into the Mac side of stuff?

David: Well, I wouldn't say "put aside," because I still was going to finish my degree. I didn't have a choice. I mean, if I was going to finish, I didn't have that choice. But what I did do was I started to learn about the Mac and tried to find spare time. I didn't want to work nonstop on anything. My physics stuff I would, at the end of the day, set aside. In the evenings, I started like...

Well, one thing that happened is Stanford was part of this original university consortium that Apple developed where they had I don't know how many universities, but Stanford was one of them where you could buy a Mac cheap. Cheap at the time meant $1,000. They were retailing for $2,400, which was for me, as a student, forget that. But $1,000 I could figure out how to get.

I started going over to the library and reading "Inside Mac." They had the loose-leaf "Inside Mac," so I started reading that. Started reading about QuickDraw. I started playing with the programs, and then I got my Mac.

One thing that was pretty formative for me in terms of programming it was, this isn't 1985 at this point. This guy, Dave Wilson, did training, and he did this thing called MacAfrica. It was around the time, I guess, of a big famine in Africa, and there was a big push to raise funds to try and help people there.

He came to Stanford and he gave a one-day thing. It was something I could afford, like maybe $100. I learned so much in that one day. It was just so different than trying to read all of "Inside Mac" and figure everything out.

I just got totally hooked with that. When I finished my degree or as I was finishing it, I had known for quite a while that I didn't want to continue in physics.

I had a very strong idea [laughs] what that was going to be like in terms of how difficult it was going to be to find jobs and my level of interest in it. I discovered over six years of getting a degree it wasn't the thing for me to continue. The Mac came around at just the right time for me, because I was like, "This is something so cool. I could see doing something with this."

As I was finishing my degree, I was doing some interviews. At the time, if you had a degree in physics, a lot of the work that was available was doing some kind of defense work in the Silicon Valley. Of course, it's totally changed now. It's just like night and day. But at that time, the idea of being a programmer was a different idea.

I didn't want to go and work in defense-contract-kind of work at all. I had some interviews for some things -- nothing that really got me excited. Then I got this just out of the blue, ran into somebody at Slack who worked in a different group. Because I was over working in physics, but I met somebody that worked in the computing center who had a project that they wanted to do that was a Mac-based project.

He basically was just as excited as I was that he'd met somebody that might be able to do this stuff. It worked out that I was able to get that job. That was my first job after grad school, and I was still at Slack where I had been working as a graduate student, but now I was in the computing area instead of in the physics community.

Guy: It's cool. What kind of software were you writing?

David: The software that he wanted was basically a piece of software that would interact with a piece of hardware that they were building. It could monitor the hardware, it could read out data from the hardware, and then it could show you graphically stuff that it was reading out, plus you could control the hardware. The part I remember, and you want to remember, this is '85, so it's a few years ago...


David: The part that I remember is that I had built a graphical interface to let you control the hardware so you could set switches a certain way and things like that from the Mac UI. That was pretty neat. This wasn't my idea, but he wanted the whole thing done in Forth. He was a Forth freak. [laughter]

David: He loved it. I guess Forth ran on this piece of hardware as well. One of the things that was so cool is I could send Forth commands to the hardware, have them execute on the hardware, and then receive return.

Guy: That is pretty cool.

David: [laughs] The software that I was writing was actually Forth-based. You could send Forth commands to the hardware.

Guy: That's cool. This is going to come back up when you talk about DPS, again too.

David: Well, maybe a little bit. [laughs]

Guy: There's something that I liked about that, but we'll get to that a little bit later.

David: I see what you're saying. I hadn't thought about that. That's actually a good point. Because to me, at least in this particular situation, being able to send to Forth was more of a curiosity, because I don't think we ended up using it a lot, but I designed it so that I could.

Guy: Yeah, it's a nifty thing to do.

David: Yeah, it was cute. One thing that was cool about Forth itself, it's, again, [laughs] a reverse Polish Notation Programming Language. It's not compiled, it's interpreted. One thing that was neat about it is, I met these guys that did a really good version of Forth that happened to be in Palo Alto. They called themselves the Palo Alto Shipping Company.

I had started with a different Forth that I'll never remember the name of, but it was the one that was premier product at the time. These guys did this Forth that you could actually compile into machine code and run. You didn't need an interpreter. If they'd had an interpreter, it was built into the binary that they built, but I don't think it was.

That was actually pretty cool. Really good guys. One thing that was pretty neat about it is, it turned out -- I didn't know this until I started looking this on the Web recently -- they were using the Forth that they were building and selling commercially, but they were using it to do their own work.

They were doing contract programming [laughs] for other people using Forth as their language of choice.

Guy: That's cool.

David: Anyway, that was the project that I was working on at Slack. One thing that was fun while I was there, it was a total PC house. They had an IBM mainframe. That was the way things were done at the time. A lot of the experiments used DEC VAX computers, stuff was starting to be networked. It was totally different than today, certainly. The cool thing was, we started to get some traction with getting Macs used at the lab. I had a lot to do with that, because I was such as Mac proponent and got very used to hitting the headwinds of the IBM PC, but that was a pleasurable thing. Then I got an opportunity to go to work for Adobe.

I actually interviewed at both Apple and Adobe. Same time I got an opportunity to interview at both places. The Adobe one worked out. I started working in their Developer Support group. This was '87 at this point.

Guy: It was an interesting time to be at Adobe.

David: It was a great time to be at Adobe. At this point, I felt like I was so lucky to hit the timing of this, because I had gotten interested in PostScript. I guess I skipped this a little bit, but while I was working at Slack and doing this Forth project, the guy who I was working for, Dave Gustafson, he was a guy interested in a lot of different things. We ended up getting LaserWriter. This was the early days of the LaserWriter. I started learning PostScript because I just thought that it was so cool to write just a tiny bit of code and get graphics to come out. It was not exactly what programming on the Mac...

Yeah, you could write code and get graphics to come out. We didn't write [laughs] three commands and here's your text.

Guy: It was so straightforward. It was almost like Logo.

David: I never learned that, but I know the notion of programs that are built to do graphics. That's exactly what PostScript was. You could write little programs and pretty easily get some neat graphics come out. I had already learned PostScript, or at least I thought I had learned PostScript before I went to Adobe. I found out there was a lot more to learn. But, I got this opportunity to go there, which was, to me, off the charts awesome.

It was sort of a mysterious company. At least at the time I was interviewing, it was the company behind PostScript, but Apple did the LaserWriter. That was the customer facing thing. PostScript, if you knew a little bit, you knew that this was behind the scenes.

Adobe itself, especially in the early days, was behind the scenes, I mean, they really weren't out front. I don't think they really got so much out front until Adobe Illustrator came out. They had fonts, but when Illustrator came out, and it was the first version which is this unbelievable program for doing vector graphics -- for artists to do vector graphics.

Mike Schuster, who worked at Adobe, was the guy behind that. He and Warnock worked on that together. Mike Schuster did the programming. John Warnock was very much into the design. I don't know if you've ever saw it, it's on the web now, but the first version of Illustrator came with a little video. It sort of showed you how to do it, and Warnock was the person doing the demos.

Warnock was the CEO of Adobe. He and Chuck Geschke founded Adobe. That you can find, and it's actually pretty neat. It's real old and cheesy, but he knew what he was doing. He was involved with the design of the program.

So, the opportunity to go to Adobe was like, "Oh, my God." This was to me one of the premiere companies at the time. I knew something about them and what they were doing, I was really excited.

I went there and I started working in Developer's Support group, which our main focus was to work with third party developers. It was a little bit like Apple's DTS, but the number of customers was fairly limited.

For me, I tended to work with the more prominent Mac developers.

Guy: Would these people license your tech? Or, they were just using it on the LaserWriter?

David: No. That's a good question, Guy, because the support groups at Adobe divided into two categories. They had what they called OEM support, and those were the people that licensed PostScript, and were working with Adobe to build it into their hardware. There were, of course, a lot of support issues associated with that. That was a different group. The group that I worked in, Developer's Support, worked with the third party developers. Aldus in Quirk, which did Express is an example. Apple was one of the people that I spent the most time with because they had PostScript needs. They were generating PostScript to print to the LaserWriter and all other PostScript printers.

Since I was sort of not focused I tended to work with the developers that were doing Mac programs. Since the system software on the Mac, the LaserWriter driver sort of took care of it for almost every application. Working with Apple was sort of the prime contact I had. Then there were some, like I said, Aldus in Quirk, which they were high-end PostScript people. They had greater needs, so I worked with them too to help them with their needs.

Guy: So they would effectively sort of bundle into one driver that you would help them debug and work out?

David: Well, Aldus had their own driver completely. Quirk, themselves, they sort of piggybacked on top of the LaserWriter driver, for better or for worse. That came back to haunt them.

Guy: Yeah, I'm sure.

David: Honestly, all I remember those days, for the Developer's Support stuff had to do with those major vendors. There were others like people that worked more with the PC side of things, they were working with people like Lotus 123, or Microsoft, who was doing their driver as a system level driver for Windows, but that was later. In the early days of PostScript on the PC side, every program that wanted to print had to somehow figure out PostScript for their application. So that was a different level of support. The driver for the Mac was pretty much handled it for everything. You do the draw and it would generate PostScripts.

Guy: Yeah. It just works physically?

David: Yeah.

Guy: Yeah. I remember reading probably Petzold, I'm pretty sure it was Petzold. But in PC magazine, around this time HP also had sort of a PostScript wannabe, right? The PCL.

David: Yeah. Let's see, what was it called? Jeez, I'm not going to remember what it's called.

Guy: I'm pretty sure it was PCL. It was like an incredibly boring name to have that stood for Printer Control Language.

David: Well, they do have PCL. That is still a language that they have.

Guy: Maybe I'm mixing it up then.

David: They had another one that they were trying to do to compete with PostScript. PCL I wouldn't describe as competing directly with PostScript. It wasn't sophisticated enough, but they were trying to do -- it's so long ago, I don't remember the name of it. They were trying to do one. PostScript won that war.

Guy: Yeah. I remember reading an article and I remember Charles Petzold, is a famous Windows author. He was into the HP one the same way that he was all excited about OS/2. Both decisions didn't really pan out that much.

David: I don't know anything about OS/2 other than it was reported to be pretty good.

Guy: I liked it a lot, it just went nowhere.

David: One of the things about PostScript was that it didn't, itself, have a structure associated with it. Adobe came up with the notion of the document structure conventions they called it. Which were to impose a structure to PostScript programs that made it possible to identify individual pages and what content a page might have, like the fonts that were required for a given page.

Guy: Maybe we should explain exactly what PostScript is, because I'm not sure if everybody knows. It's a very basic language, well, I say basic.

David: [laughs]

Guy: It's a simple idea for a language where you have a series of graphic commands, like move to, line to, and various arcs. You can display text and you can say, "OK, that's the end of my page." There's a lot more to it, but that's the basic notion everything. It's turn complete in that you can jump around, and you can do loops, and conditionals. Which makes it really hard to have certain expectations for any given piece of PostScript code. Which I suppose these kind of document conventions come in, right?

David: Yeah. Actually, you sort of identified a couple different things there. One of them is the structure. The other is, and sort of where PDF came in, to change that. PostScript was just a free-form language and you could have five lines of code that would draw infinite number of pages. If you wrote your code that way nobody would ever be able to separate pages or reorder them, or anything like that, which was something that was potentially interesting. The language that you're talking about that HP did, that I'm totally blanking on the name, they actually made the structure part of the language itself. I think that was the contribution that they made.

I don't know how the imaging model compared. I don't know any of that. But, it didn't go anywhere which is part of why I don't remember very much about it.

Guy: Yeah, it was just an interesting footnote. For some reason I just remembered, reading through the notes here I just remembered HP doing something kind of similar.

David: Yeah. They did. So one of the best things that I really wanted to mention about when I first started Adobe. One thing is the company is 150 people. In the earlier days, they were growing the company very slowly, intentionally. There were a lot of times where people were just clamoring for more head count, and they grew the company pretty slowly. But, to show up there when there was 150 people, it was all one building. I pretty much, at one point, knew everybody, and so I'd go to spend a lot of time with people who were implementing the PostScript language, and designing things. Designing the language itself, but also one of the most fun parts of it was, the Developer's Support group was located just around the corner from the Marketing Communications group.

Those people were responsible for creating the graphics that Adobe used to market their products. PostScript being one of them, but fonts, Adobe Illustrator, those were the only products in the early days. They were using these tools to create these graphics, and these were artists using what were then, for the personal computer business, a state of the art of the tools for doing graphics.

They just did stunning work, and it was really a lot of fun to be around. I'm not an artist, I mean, I can draw graphics on the computer, but I'm not an artist. To be around people that were really so proficient with the tools, and also, they had a lot of input.

Russell Brown, who is one of the people that worked in that group, he had a lot of input into future versions of Illustrator. Then Adobe acquired Photoshop, and so on. It was really a neat symbiotic relationship between that...

Guy: Yeah. That's good. You really dug dog food in knee deep in the products really.

David: That, but more than that, in that they were pushing on what should be in the products. They had a built-in, sort of...?

Guy: Focus group, maybe.

David: Pretty much. Every now and then, they'd run into a problem. They would come to somebody like me in Developer's Support and say, "Hey, this isn't working right." I don't mean in the software, but I mean when you got down to printing it and something was wrong, I could get in and I could look and help them out. It was really, sort of, a bonus when you're working with a lot of engineering types, and then you also get a chance to work with a bunch of artists. That was really a fun aspect of working there.

Guy: I'm not surprised you say that, because it's one of the things I really liked about working in the games industry. It's like there's a bunch of programming guys around and you're interacting with artists constantly. Day in and day out. It just kind of shakes things out and it's a lot of fun.

David: Then they're producing this amazing stuff. To see what they were doing with the tools that you were creating, I mean, that is...

Guy: Such a good feedback group.

David: Yeah.

Guy: Right.

David: Yeah. They were driving it too, which was really, sort of, a cool thing to see. One thing I wanted to mention that was cool and I thought you mentioned it a little bit ago, which is Display PostScript. Right around the time that I came to Adobe, maybe little bit later. Adobe had already been pretty successful in the PostScript language, and licensing the OEMs, and it was really taking hold I think. They thought that the next step was, "OK, let's turn this to the graphic software that drives the displays." One of the big targets for that, first of all, they licensed it. DEC was one of the big licensees at the time. Digital Equipment Corporation, which doesn't exist anymore. At the time, they had mini-computers, or they were super powerful.

Guy: Yeah, they were pretty high-end stuff.

David: Adobe was hoping that they could get Apple to license Display PostScript and use that. I don't know if they thought this... [crosstalk]

Guy: In place of QuickDraw, or as a...?

David: That's a great question. [laughter]

David: What did they think? I don't know. What would I have imagined? If Adobe had been successful, what would it have turned into? The most I could've imagined was it was something in addition to QuickDraw. In '87, '88, '89, that time frame, QuickDraw wasn't that old. They made Color QuickDraw, 32-Bit QuickDraw, it extended it a lot. While I thought it was a really cool technology, I just could not imagine that Apple was going to license it.

There was a certain tension between Adobe and Apple over a period of time, because of PostScript licensing fees for the printer. Now, you're talking about PostScript on the desktop. PostScript had a reputation for being slow, and certainly not at all what you want when you talk about a programming language for interactive graphics. It's just a nonstarter, but they had it running.

Guy: On the Mac?

David: They had it running on the Mac, yeah.

Guy: Cool. Crazy, but cool. [laughs]

David: Well, it wasn't crazy, because it was a big project. It was part of their project, they licensed Display PostScript to NeXT. NeXT had made extensions to it. They added the compositing extensions that were never folded into the language, really. They did their own thing with that.

Guy: For some reason, I don't know, it's just one of those things that I really liked about the NeXT machines, which was Display PostScript model. I think, mostly, because it was really novel, to me. I found it a crazy idea that you could upload code.

David: That's what I was going to ask you. What is it you liked about it? I'm just curious.

Guy: I think, I had less experience and I thought it was cool... [laughter]

Guy: ...that you could upload code. Of course, it was kind of dumb, because you could lock up your display. If you sent a series of commands, it would print an infinite number of pages, and you sent them to your display. Guess what? Your display is locked up now.

David: Yeah, well they built in a multi-threaded model into the language.

Guy: Yeah, there were steps taken so that that kind of stuff wouldn't happen.

David: Well, your goal was to avoid it.

Guy: Yes, exactly.

David: [laughs] The world has changed, in this regard. Now, people are doing hacks to try to break things. At that time, the idea was to use the language as it was intended, in order to avoid things like that.

Guy: One thing I liked about the NeXT was the accelerated board that they did. I just thought that was such a great idea, something you wouldn't see today. Basically, it was a graphics card that you'd stick in. It was full of computer that would just do the interpreting of Display PostScript and display it.

David: I remembered they had some add on card that they were touting for awhile, but I don't remember the details about it. I don't remember what was in it. I remembered they were making a big deal about it. They'd also had RenderMan, that they were trying to push at the time, for the NeXT machine. One of the things I thought might be moderately entertaining, is just a little bit about Mac Display PostScript, because...

Guy: Yeah, definitely.

David: ...I don't think there's been a lot talked about it, other than, maybe, people at the time knew that Adobe was hoping that this would...

Guy: I loved this kind of stuff and had no idea that it was ever running on the Mac.

David: I'm trying to remember the timing. I'm trying to remember if it was when I arrived or was soon thereafter. Certainly, at the time that Adobe was licensing it to NeXT, it was running on the Mac. I don't know what the upfront efforts were, with Apple, to try to talk them into it. I wasn't working at that level of the company at all. What I was doing, was I was working with the third party developers that Adobe was working with on PostScript related stuff. Adobe, in all of this, had a really close relationship. Paul Brainerd, who founded Aldus, and John Warnock, I think they were really good buddies. There was a lot of synergy between PageMaker and the LaserWriter, or PostScript, in general.

They had a really good working relationship. One of the things that happened was that Aldus was, I think, seriously looking at licensing Display PostScript for the Mac, for their own use. It didn't look like anything was going to happen with Apple. I was working with the Aldus guys, for their integration of the Display PostScript that Adobe had done for Mac, into PageMaker.

They had it running. The big thing about it was the type. Maybe back up a little bit and say, one of the biggest things about PostScript, when it actually hit the market, was that the quality of the type was really something not seen before on 300 dpi devices. The quality of the fonts that Adobe and others produced for PostScript printers was really excellent quality.

That was, I think, the primary interest that Aldus had in PostScript, so that in their text rendering, you could have really high quality text rendering, when you didn't just have bitmap fonts at whatever size. That's the way the world used to work, right? You had...

Guy: It's just a great goal. Plus, I think, if you're a hardcore graphics guy, the PostScript model makes a lot more sense.

David: Well, I think it fit more with what they were doing in PageMaker, too.

Guy: True.

David: Things had gotten to a point where people were working around the limitations of QuickDraw. As great as QuickDraw was, in its day, people at the higher end were running into limitations with QuickDraw. So they were running their own graphics routines. I know, all of the Adobe stuff, that the only thing they used QuickDraw to do was to blip the graphics they'd already drawn, using their own internal routines onto the Mac using CopyBits. I don't want to say they didn't use QuickDraw, but Illustrators One was written with a rendering engine that was a PostScript type rendering engine. Basically, Aldus had it running. I think, at the time, they were thinking of doing something like PageMaker Pro. You'd have PageMaker, but they'd have the Pro version and Display PostScript running underneath.

The first time you see really high quality text rendering, when all you'd seen was bitmaps, before, it was pretty impressive. It had some downsides, for sure, because you're running a PostScript interpreter, underneath. The other thing, besides text, was the idea that you'd take PostScript graphics -- there's a graphic format called Encapsulated PostScript files that was in the higher end graphics circles, was the way you interchanged graphics.

QuickDraw had PICT, which was just a recording of QuickDraw drawing commands. PICT could be any QuickDraw captured graphics.

Guy: Cool, I didn't know that.

David: Yeah, and...

Guy: Microsoft had one, too.

David: I forget what it's called.

Guy: Whatever.

David: There was this Encapsulated PostScript, which was basically, now, there it was bunch of PostScript commands, which drew a graphic. Then associated with this was a PICT, which really was a bitmap, that was the graphic at low resolution. You'd stick that PICT in as a proxy, but when you'd go to print it on a PostScript printer, you'd get this really high quality graphic that was drawn by the PostScript commands that were backing up the bitmap graphic.

Guy: That's a pretty cool idea.

David: I don't think Adobe created that. I think it might have been Aldus, or it might have been one of the other high end vendors, like Quirk, or whatever, in the early days when you wanted to be able to interchange high quality graphics. PICT wasn't of sufficient quality for this. Really, what ended up happening, and that leads into, I would say, the rest of my career. [laughter]

Guy: Things heat up between the two.

David: At least, the way I understood it, not just from being inside of Adobe. What was reported in the "Popular Press," was that Apple was fed up with paying licensing fees to Adobe, for PostScript, once it got so successful. Apple sold a lot of LaserWriters. Other companies sold PostScript printers, too. The licensing fees were reported to be steep. They wanted to cut down on those fees. I don't know exactly how it all came about, but basically at one point, Apple decided, "OK well, we're going to license this PostScript clone, from Microsoft."

Microsoft, I guess it started up some PostScript business, I don't know. Microsoft did everything, right? Of course, they had a PostScript clone, over there...

Guy: [laughs]

David: ...that they, you know. I guess, Apple was going to license that and they also were enhancing QuickDraw. They did this thing called QuickDraw GX, which was really a total new graphics model. The fact that it had QuickDraw in the name was the only connection to QuickDraw, really. They were going to replace the printing system that existed on the Mac, with the one that was encrypt on GX, which was, supposedly, more sophisticated, and so on. Also, they developed TrueType, which was a font rendering technology that was outline fonts, like PostScript had, that is vector. Essentially, which are fonts that were vector art, instead of bitmaps. They were going to compete with Adobe's PostScript Type 1 fonts. They replaced the use of Type 1 fonts, with the TrueType fonts.

I think what happened is Apple did a deal with Microsoft. They gave them TrueType and Microsoft was going to license PostScript, their PostScript, TrueScript, or something. I don't remember what the name was.

I'm sure I'm getting into this too much. Basically, the outcome of all of it, was that there was a lot of pressure on Adobe to not only compete with TrueType, in some way, because Apple was going to build outline fonts directly into the Mac, but also to enhance the PostScript language so that if you're going to license PostScript, what you're licensing is not the good stuff from Adobe.

That was always true, but they were going to enhance the PostScript language to have more capabilities and whatnot. That's, sort of, the beginning of my real career in software engineering. I was very much involved with both extensions to the PostScript language, because at that point I knew a lot about the language itself, and what the deficiencies were.

Especially, when trying to generate printing commands from the Mac, from QuickDraw graphics, but just in general, what the deficiencies were. For example, there was no notion of patterns in the PostScript language. The way you had to do patterns was almost a complete hack in PostScript. That needed to be added. There were a lot of things that got enhanced in the language.

Adobe called it PostScript Level 2, it's at the next level, I guess. The idea was, "Well, why would Apple, who had been a partner with Adobe, in buying PostScript from Adobe, why would Apple not want to get PostScript Level 2? Instead of this old, whatever Microsoft was peddling." One of the flies in the ointment was that Apple owned the LaserWriter driver.

The LaserWriter driver was the thing that took the graphic commands that Mac applications generated, and would translate them into PostScript, so you could print. If you didn't update the LaserWriter driver to use this new PostScript Level 2, then there wasn't really any reason to have PostScript Level 2.

Guy: Right, what originally made PostScript so great on the Mac, and with the LaserWriter, is now kind of standing in the way, because there's a feud going on between Adobe and Apple.

David: Pretty much. To solve that problem, they said, "OK, you guys... [laughter]

David: ..."You guys" was one of my colleagues at Adobe, who I really didn't know very well at the time, Richard Blanchard. He had done printer driver work for the Mac, previously, to come into Adobe. I knew the PostScript stuff, so he knew how to do a QuickDraw driver. I knew PostScript, and I knew a lot about the LaserWriter driver. So, they basically said, "OK, you guys, make a new driver." Make a new LaserWriter driver was essentially what we were tasked with doing.

We started on that, and again, the goal was to use PostScript Level 2 as much as possible, to enhance the abilities of it, and make it fast. Make it faster than LaserWriter driver, so it was compelling to why you would want to use this thing, instead of whatever Apple had, and use it as part of selling PostScript Level 2 to the vendors. We started that project in June of 1990.

You guys tell me, do you remember an Adobe Developer Conference, ever?

Guy: I do, I never followed it, particularly.

David: I was just wondering. [laughs]

Guy: I was in PC land, at this point.

David: Oh, OK.

Guy: There was only ever one?

David: There was one, and it was in June of 1990.

Guy: OK, maybe I'm confused.

David: It was basically because Adobe was introducing PostScript Level 2. It was a very different kind of conference than the WWDC Conference, because most of the vendors that were there -- most of the people that were there -- were from the companies that were potentially licensees of it. We had sessions running, so by that time, we actually had a driver that you could print from. You could print basic texts and certain graphics, and whatever. We could demonstrate that it was really a lot faster. Actually, the internal code name for this was called Screamer, [laughs] because our goal was to make it scream.

Guy: That's nice. [laughter]

Guy: So, one detail about this...

David: Yes.

Guy: ...is that you decided that you wanted to compute the PostScript output on the host rather than sending it to the printer? Because I think that's a pretty key technical decision that is still echoing today.

David: To clarify it, just a little bit, Guy. The way the LaserWriter driver, and an awful lot of PostScript drivers, worked at the time was, well, PostScript's the programming language. So take whatever graphics you're trying to draw, and then take whatever the graphics format you have is, together with the program that can interpret that graphics format, and then draw that on the printer. The computation was done in the PostScript language, in the printer. This is still true, today. The hardware that's running on your desktop is a lot faster than the hardware that's in your printer. This is the case. One difference that we had, with the LaserWriter driver, besides having a lot of PostScript experience, myself, but one key thing that we were trying as much as possible to do, is have less work done in the PostScript language.

Yeah, we used it as a programming language, but sparingly. Where you could get advantage by using the programming performance wise, then, yes. It's a lot easier to do multiplies and divides, and whatever computationally, in the host generating the PostScript that you're going to send to the printer than it is to do all the adds and divides and multiplies in the printer.

You're running an interpreted program, and the hardware isn't as fast as the hardware on the desktop, either. That was pretty much a design goal of the printer driver, that we were working on, which was to...

Guy: The reason I'm focusing on Mac, is that it turns out to be an incredibly good decision, because down the road, video cards end up being the same way. In that, it's better to compute it on the host, than stick it into a texture, and manipulate it using compositing on the GPU, than it is to have some kind of GPU that's trying to interpret your graphics commands directly.

David: This has been a real thing, I'm skipping ahead just a little bit, but... [crosstalk]

David: ...one of the questions is, "How to accelerate 2D graphics on a personal computer, now?" It's some of the same kind of thing, it's not that easy a thing to do. We worked on this printer driver project and it took awhile because you're basically replacing a piece of software that interacts with every application that prints on the Mac platform, all of their idiosyncrasies, in the way that they interact with the existing LaserWriter driver. The goal we had was to be functionally equivalent, plus to add features. We had some features that we were adding, besides performance. Among other things, one of the things we wanted to do was be able to generate Encapsulated PostScript files, and be able to take the stuff you were going to print and make a graphic out of it, that you could, later on, use to drop into another application.

We were trying to add some things, in addition to get really high quality PostScript on very fast performance, and be compatible. Compatible was the key.

Guy: That's right.

David: This ended up being a big project, instead of a smaller project. One thing that was great, is that, after about a year of this, and we were demonstrating to Apple what we were doing here, and how much better, at least we thought, and I think they agreed that what we were doing was, than what they were already shipping. The other part of it was that they were working on QuickDraw GX, and they had taken all their development effort on anything related to printing, and they poured it into QuickDraw GX. There was no question that the traditional Mac, if you want to call it, Mac Classic, that's probably a bad word to use, now.


David: The Mac QuickDraw printing system that existed, prior to QuickDraw GX, that was being totally neglected, because of the QuickDraw GX effort. We were...

Guy: A lot of bad decisions at Apple, at the time.

David: Yeah, well that's one way...

Guy: Well, maybe not bad, but like a...

David: That was...

Guy: "Shoot the moon" engineering, really.

David: It did, exactly. Basically, we ended up being their printing team, because Adobe and Apple struck a deal where we, at Adobe, continued to work on this LaserWriter driver substitute, at Adobe it was called PS Printer. Apple was going to ship it. They provided to us, as their effort -- it ended up being a joint engineering project. The way it became a joint engineering project, was Apple provided all the testing. I don't want to say all, Apple provided a huge amount of testing help, which was fabulous. Because jeez, think about all these testing apps with this new driver. Plus, they gave us access to the LaserWriter source code, to look at for issues that related to compatibility, and there were plenty. Now, the LaserWriter [laughs] code, at that time, was all assembly, 68k assembly.

This was 1990, '91, that time frame, way before PowerPC. It was all 68k assembly and a big part of my role with the project was where we needed to figure what the LaserWriter was doing in some oddball case, it was figuring out what the hell it was doing, from the source. I shouldn't say it was all assembly, there was a lot of assembly. What wasn't assembly was pass and go.


Guy: It's like pass and go defines the functions and just everything else is assembly.

David: No, honestly I don't [laughs] remember, anymore. It was a long project. It ended up shipping, pretty much, in the same time frame as PostScript Level 2 did, which was in the '92-93 time frame. I don't remember exactly. But there was a lot of pressure on us. [crosstalk]

David: Pardon me?

Guy: I'm trying to line it up with a Mac OS release. '06, '07?

David: Well it was, let me think. It had to be '07.

Guy: Yeah.

David: It had to be '07.

Guy: Whatever. I'm sure that's right.

David: Seven something. Seven something. I don't remember. One thing that was interesting, at that time, see the driver was decoupled from the OS. I mean as the OS got updated there might be some things that we would add to the driver but we actually weren't. This is one thing that made development a lot easier and certainly that, this changed as time went on.

Which was to work on the printing system we could do a lot of work independently OS changes when we're working on just this driver. But there was a lot of pressure on us in terms of time. The goal was to ship this when PostScript Level 2 shipped. At the same time, it had to work as well as the LaserWriter driver or better, and so on.

Guy: It's a big bed for the company, right?

David: PostScript Level 2 sure was. At that time PostScript was still a big money maker for Adobe. Obviously, that's changed dramatically.

Guy: Level 2 is far less useful until you can actually use it in the field.

David: Absolutely. Why do you want to license it if there's no obvious benefit to it? Nobody is really using it. It was a chicken and the egg thing. Which is why the driver project existed at all. One thing that was sort of cool was, this is also around the same time frame as PDF is being created at Adobe.

Guy: I was going to ask because a lot of the sort of conceptual problems with PostScript and Display PostScript must have been sort of coming to light as you were designing PS Level 2.

David: I think what's true is that it was pretty clear that Display PostScript wasn't going to take over the world, you know? No way. So you weren't going to have some client that could render -- like every client could render PostScript graphics. That was not going to happen. The interchangeability of content -- PostScript was actually, at the time, a relatively portable way of taking a document and handing it from person to person and they could then print it. You could just send the PostScript to the printer and...

Guy: High fidelity documents, basically.

David: Absolutely and all the layout was already done and everything, right? But you couldn't see it on the screen unless you had a PostScript interpreter and that wasn't going to happen everywhere. An awful lot of things about PostScript that weren't particularly practical for things like searching text and stuff like that. So, I can't speak a lot to the origins of PDF really where it started. I'm sure Warnock had a big hand in it. He gave a lot of talks about what he called ASCII jail. We're all in ASCII jail, you know. The only way you can send something from Person A to Person B is to put it in ASCII because if you do anything else then they're not going to be able to see it the way it originally was formatted.

PDF came about as way -- originally there was talks about making it an editable interchange format and that was clearly too big a task to take on -- it became non-editable. Well, I mean, you can edit it, but as a general rule, just a way of taking a document and handing it from person to person. It's been incredibly successful.

Guy: I think that scope of making it not editable is probably the right decision.

David: It was the only practical one at the time, that's for sure, because as soon as you add edibility there's just a whole range of problems you've got to try and solve and that was just beyond what was reasonable to solve in any reasonable time frame. What is the editable format now? Microsoft Word?

Guy: There isn't one and I think it's almost an unsolvable problem, right?

David: Good that Adobe didn't try and force that to be the solution in 1993 that they were going after and never would've solved. I don't want to say never would've solved, but they weren't going to ship it in 1993. That driver project was pretty much my undoing at Adobe, just because of the stress involved with that project and mismanagement. Pardon me?

Guy: Just burned you out?

David: Well, there was a bunch of mismanagement. There was a lot of stress, that was pressure, that was put on in terms of being able to deliver. I have a little story if you'll indulge me. You can edit it.

Guy: That's what we're here for.

David: You can edit if you don't like it. But, this I think is representative of the mismanagement. It got to the point where there's a lot of pressure to ship this in such and such time frame. They were having regular 8:00 AM meetings everyday, where they would go over the status of this project. So, my manager at the time was going to these meeting at 8:00 and reporting about the project. I don't know about you, doing daily status reports isn't going to get the job done. That doesn't get the job done any faster.

Guy: It's going to make it worse.

David: All you're doing is writing your status report. [laughs] One time he comes back, we thought things were going pretty. Our bug counts were down, seemed liked we were zeroing in on getting the software finished. He comes back from one of the meetings and he says, "Jeez, I just reported to the guys today. Things are getting worse, and at the rate things are going it's going to be whatever amount of time before we're done." I'm like, "What are you talking about? Things are going better bug counts are down." He says, "Well, look I've worked the numbers and here's the projection of when we're going to be done." I looked at what he had and I said, "Show me. How did you generate this chart?" Or whatever it is he had. "How did you generate?" He said, "I wrote an ArcScript to take the bug counts and project out."

I said, "Can I look at your code?" I didn't know Arc. [laughs] "Can I look at your code?" I looked at it and he had in his calculation for projecting out, he had the numerator and denominator of the equation, so that the faster we were fixing bugs the longer it was going to take us to finish.


David: I was just like. I looked at this and by the way, it's not like this is the first time this particular person had done something that made it impossible. [laughter]

Guy: I can't believe this. [laughter]

David: By the way, that's bad enough.

Guy: It really is mismanagement. That's just wrong management. It's provably mathematically wrong management.

David: Well, yeah, but look at it this way. If all he had been doing was giving us internal reports on our team and this had been the case, that would have been one thing. But every morning, he's going at 8:00 in the morning and telling upper management at Adobe, "This is how the projects go." And I'm just like. [laughs] So, anyway. It's like, "OK. Well, we better stop fixing bugs because the more bugs we fix the longer it's going to take." So, anyway.

Guy: Oh, my God.

David: So...

Guy: To be fair, he's management. He should have spotted that what he was saying wasn't making any sense.

David: So, "Gus, I'm just not all that interested in being fair." [laughter]

Guy: OK.

David: Probably, I'm sure. What can I say? Let me also say, I worked with some really great people with Adobe both on the team and other managers that I had at Adobe. I had some really good ones, but the engineering management on this project was abysmal. Working under that kind of stress with those kinds of screw ups takes a toll.

Guy: I can imagine. So you basically quit.

David: No, I wouldn't say that. Basically the driver, we finished up the drivers. I took a six week sabbatical. I took six weeks, part of it was time off, just to get away, and got relaxed. Then, I came back and two days after I got back there was already some emergency crisis. Then, I'm right back in the totally panicked running around. So, I lasted about six more months at Adobe. Part of the reason that I left was this, and another part of it was I got a really good opportunity or at least what I thought at the time was a really good opportunity. Which was I got approached by somebody that I used to work with at Adobe who was working at a company called General Magic.

Which was, in retrospect now, one of the storied failures of Silicon Valley, but at the time was doing some of the greatest, coolest stuff on the planet. They had just an incredible team of all-star people that had been put together. They had two separate products that they were working on. One was called Magic Cap and the other was...

Guy: Which was pen-based computing, right?

David: It was pen-based computing. The two people whose names kind of grabbed your attention at the time, two of the founders were Bill Atkinson and Andy Hertzfeld, who were formative members of the Mac team. I got an interview over there. Andy demoed Magic Cap for me. He demoed it running on a Mac, but he clearly had it running on a device as well. It was really amazing. Anyway, you can go look up Magic Cap and look at some of the demos and stuff.

Guy: The people who were there were pretty heavy hitters.

David: The thing about it is, at the time I thought of Andy and Bill as the big, heavy hitters. After I was there for a while, I realized there were quite a few others. One of the people who I just thought was an amazing guy was Phil Goldman. He had actually, if you remember this product that Apple had, it became part of the Mac, called the MultiFinder. He was one of the authors of that. It was sort of Andy Hertzfeld's Switcher program, but it basically made the Mac look like it was a multitasking computer with a multiple-windowed system that had multiple applications running at once. You could see the windows were all applications at the same time, which at the time was not the way the Mac worked.

But Phil was just an amazing guy. It ended up being an all-star group of people. But I didn't know most of these people before I came there. It's sort of interesting what came out. Some of the things that came out of it were, Pierre Omidyar who started eBay, and Andy Rubin who, he started this company called Danger.

Later they had Danger phones, and obviously was sort of the seminal force behind Android which ultimately was bought by Google. We know what's happening with Android now.

Chris MacAskill stated this company called SmugMug which is really one of the premier photo publishing sites on the web. Phil Goldman, Steve Perlman, Bruce Leak -- Bruce Leak had been one of the QuickTime architects at Apple. He was at General Magic. When he left there, he and Steve and Phil started this thing called WebTV that later on got bought by Microsoft.

Guy: Microsoft. Yeah.

David: Yeah. Kevin Lynch, who's been in the news a lot lately because he was at Macromedia and ultimately Adobe, and worked on Flash. He certainly became a figurehead for Flash. I don't know exactly what his role in working on it was, but he was at General Magic.

Guy: I feel that maybe he got a little bit tarred for that. Maybe unfairly.

David: I don't know. He's become a figurehead for Flash, whether that's justified or not I have no idea.

Guy: Yeah.

David: He made the video so he earned it.

Rene: Yeah. [laughs]

Guy: But, I mean, he's been doing interesting stuff.

David: Yeah.

Guy: This is an all-star cast.

David: It was an all-star cast of people. Magic Cap, you know, it was amazing software. The thing about it is, the time frame we're talking about, '93, '94, '95, the hardware wasn't anywhere near where it needed to be. The size of a Magic Cap device, I'm sort of putting my hands out trying to estimate the size. Maybe it was like, eight inches by five inches, maybe, I don't know. It was really thick, maybe an inch and a half thick or something like that.

Guy: If I remember right it's almost like, you know when the UPS guy hands you a device?

David: Yes, pretty much that size.

Guy: It's almost that bulky.

David: It was about that bulky. It only had a telephone input. You could get one, one of the first ones that shipped from Motorola had wireless, but wireless was a fortune. There wasn't a World-Wide Web. Telescript, which was this language that General Magic was creating, and that's actually what I got hired into, was to do developer support for that. Telescript was being used by AT&T to make a service, a mail service, plus they were going to do other things as well, that the Magic Cap device was going to talk to. So that's how you're going to have your email, was through AT&T Personal Link is what it was called at the time.

I mean, this was really before the Web. It was way ahead of its time, before the hardware, before the communications had gotten to the point where it really needed to be to make such a product viable.

It was just way too big, too. I mean, when Palm came out that was really the device that took the world. When they came out with their devices, that was something you could hold in your hand, you could put it in your pocket. The Magic Cap device was a big device that you pretty much had to have some kind of handbag. I would say...

Guy: I think it's fair to say that Palm took a lot of ideas from Magic Cap and General Magic.

David: I don't know, because I didn't start getting into that. I wasn't that interested in Palm. It wasn't anywhere near -- Magic Cap was like this thing where you had a desk in front of you and you had a telephone. If you wanted to make a phone call you touched the telephone, and the telephone would expand out, and it had your contacts. I mean it was pretty well done. Visually really interesting, very smooth. You know, they were onto a lot of stuff. It had a stylus. That was the hardware of the day.

Guy: Yeah.

David: You know. Anyway.

Guy: Ahead of its time. I think it's...

David: It was ahead of its time, definitely. A lot of good people came out of it. I mentioned the people that you heard of. There's a lot of people you'd never heard of that have gone on to do great work, a really talented group of people there. It wasn't really a good match for me. I was working on this other stuff called Telescript. I think the fact that it had the word "script" in the word was sort of why I thought...

I had done developer support. I knew how to work with third-parties. I had done engineering work and I could do things from that point of view. It really wasn't something for third-parties to work with, it turned out.

Pierre, who ultimately started eBay -- the company he worked at which was called eShop, they were my only developer that I was working with. I had third party developers, they were really the primary one.

They were trying to build a shopping service kind of thing that was going to be visually based, you were going to walk through their stores like a little virtual-reality store you could walk through. They were very ambitious. People were very ambitious.

Guy: Well, it was the 90s.

David: Yeah. Wasn't very practical, it seemed.

Guy: That's OK though, it's part of the learning -- the communal learning about how stuff should be or how it could work.

David: I think you're right. But I've got to tell you that, at that time I was very focused on making sure that a product was going to be successful. If it didn't seem like it was very practical for me, that didn't fit me very well.

Guy: Don't get me wrong, I'm the same way. I'm very product-oriented, at the same time as I don't think this is necessarily a misstep in history. I think the work that went on here is all interesting, and it's informed the other work.

David: Pierre, he left that company. They ended up selling that company to Microsoft actually. He left that company before they sold it and came to work in Developer Support at General Magic to do Magic app support for third parties. This is after I had left General Magic, but he was at General Magic when he developed eBay. People absolutely learned from their mistakes or what they've done in the past for sure. Just ask somebody doing developer support. When you see that the one developer that you're trying to support is...

It doesn't look very practical. The technology that you're providing and what they're doing didn't seem very practical. At that time, I didn't feel very successful there.

Guy: I can see why it should have been depressing. So you've basically quit.

David: [laughs] No. Based in my experience, no.

Guy: I'm kidding. I'm really abusing.

David: No. I left on amicable terms. It just wasn't a good match for me. Plus, here I am living over in Santa Cruz, and I had to drive everyday to get to the office. I had been working at home a lot prior to that. It just wasn't a good match for me. I was there for almost two years and just decided it wasn't working for me. What I ended up doing when I left there, which led into my latter part of my career. To me, the most interesting part of my career. Rich Blanchard and some of the people that I had worked with at Adobe had left Adobe.

They started contracting company, consulting company, and they started continuing work on the printer driver work that we've done while employed at Adobe. Both Adobe and Apple had, because it was a joint development deal, they both have rights to source code for this software. We didn't have rights to the source code. They owned it.

Since we had the knowledge, we had developed the software, we had the opportunity to continue software development but do it as contractors. In '95, when I'd left General Magic, I went and started working with Rich and his company. It was called RBI Software Systems, and we did contracting work for both Adobe and Apple.

We had other companies, too, and the most interesting one was Sun because we did the job, a TD Printing System. Basically, when they integrated printing into Java 2D, we'd wrote the software for that. We designed and wrote the API and the software for it.

We wanted to do Be. At that time, BeOS was potentially a really hot thing. They were doing really cool software. Who knows what was going to happen with the hardware? Do you guys remember Be?

Guy: Yeah, totally.

Guy: I was a huge fan. I'd really want to buy a Be Box. You could pre-order them for a while. They had a specific video card in it, which I'm forgetting, that I went out and bought for my PC just because I was like, "Well, it was good enough for them [laughs] . It's good enough for me." I was a huge, huge fan.

David: Between NeXT and Be, those were the two operating systems that supposedly Apple was considering when the Copland project fell apart, and they were going to license or buy another company. Be was Jean-Louis Gassee's company. Anyway, we wanted to do that, and we somehow didn't know the right people to get connected to do the printing stuff for Be because that was our specialty. We know how to do both APIs and the software underneath them and stuff.

Guy: It was a funny thing. One of the issues with Be was A, it was single user at the time when it was looking like that, it was going to be limited. But I think one of the negatives was that they didn't have great printer support as compared to what Mac currently had. It would need to be something that they worked on.

David: Guy, you can recommend me [laughs] .

Guy: I'll call up Jean-Louis. Me and him are tight.

David: We just didn't know the right people to talk to. I don't know.

Rene: If Palm owns it, does that mean HP owns it now? So it's kind of full circle.

David: That's true that Palm bought it, and I had no idea why they bought it when they bought it. I had a friend that worked at Palm around that time and like, "Why in the world did they buy that? What in the world..."?

Guy: I don't know if they knew.

David: To me, it made sense that HP bought the Palm software. That made sense to me, although what they did with it didn't make any sense to me. That made sense to me. With this side, I never understood the Be reason. What ended up happening ultimately, we're at RBI, and we're working on updating the printer driver software, plus doing some stuffs for some other companies and whatever. We were pretty busy doing that. We've got a lot of work from both Adobe and Apple.

But 1996, 1997, Apple bought NeXT, or NeXT bought Apple, or whatever. The companies merged. At that point, it looked like Display PostScript, which is what was running on the Next-Box. Maybe Display PostScript was going to, now, all of a sudden, be the graphics language of choice for operating systems.

Guy: This is when they get excited about it. [laughter]

Guy: Because they had never really had access to it before. I was like, "Oh, cool. I'm going to get to play with it."

David: You could have bought the NeXT software. You could have bought OpenStep and put it on a PC if you'd wanted.

Guy: Yeah, but 10 grand at that point in time in my career...

David: Is that what it cost to get a license?

Guy: Yeah, it was crazy.

David: I didn't know about the software. I know... [crosstalk]

Guy: Sorry, I say 10 grand, but it was expensive. It was more expensive than I was going to pay. Around that time, I paid 700 bucks to IBM for a compiler, a C compiler. Things were not cheap in those days.

David: That thing at IBM, that's another matter. It really affects them.

Guy: Exactly. Anyway, it's funny because you're depressed this is coming back, and I'm like, "Oh, cool."

David: No, I wasn't depressed it was coming back. No, don't get me wrong. I wasn't depressed it's coming back. As a matter of fact, that was potentially a real opportunity for somebody like me as a PostScript expert. It could have been that it was going to generate a lot of work. I think what I was depressed by, and just about everybody in the Mac community was depressed by, was how poorly Apple had been doing. I don't know of the story that Steve tells is true that Apple's 90 days away from bankruptcy and all of that stuff. I have no idea. It's a great story.

Guy: It's a matter of the truth. Exactly. It feels true.

David: It's a great story, and it's close enough to being true based on just the feel of things was not very good. Prior to this, we're thinking, "OK. What happens if Apple doesn't make it? Are we going to be a Window shop"? None of us could stomach the idea of that. We just didn't want to do that kind of programming. So Apple and NeXT merged, and maybe Display PostScript is going to be the thing of choice again.

Guy: They did ship a product on it, right?

David: Yeah, I heard you talking with Daniel about it.

Guy: Nobody bought it.

David: I didn't remember what he said, but I believe.

Guy: In fact, OS X up until DP-3, developers for DP-3 were shipping with the Display PostScript.

David: That I knew, but what I didn't realize is that they'd shipped a "1 mod 0." You said in another podcast that they'd shipped a "1 mod 0" with Display PostScript.

Guy: Yeah, they were crazy.

Guy: And I'd forgotten it completely.

Guy: That's OK. Nobody bought it except disaffected NeXT people. [laughter]

David: Look, I don't want everybody to think that I thought Display PostScript was terrible. I just personally thought that there was a better model. The PostScript imaging model was great. The thing with Display PostScript was that in order to draw anything, you had to package up your drawing commands and send them to the Display PostScript server that was running inside your box. It was going to interpret those drawing commands, and then render the graphics to the display.

Guy: To be clear, I thought that was neat.

David: I think it's neat, too [laughs] .

Guy: It was just the stupidest way to design. Like, "Hey, that's kind of neat." You know, no. I've since learned that that's the dumbest thing to do. Well, not the dumbest, but.

David: This is just an example. Like I said, my friend Rich, who I had been working for a lot of years you know, he was working on some software for the Next-Box. He was asking me for some tips on how could he get images to go faster. With all kinds of ideas, and you tried every damn on. None of them could make it go faster because basically you had to send your image to the server as opposed to just...anyway.

It really didn't turned out to be a very practical solution in my opinion. The notion that you could send your program across the network and had it interpreted, that's sort of cool.

Guy: That was one of the cool things I like because you can draw your app on another machine over the network, and it would render as if it was rendering locally.

David: I don't know. I'm not a fan of it in terms of as a practical solution for real world problems.

Guy: They're the next Windows.

David: Pardon me?

Guy: It's better than X11, I guess.

David: Yeah, that's what Deck did. They built it on top of X11. When Adobe licensed Display PostScript to Deck, they built it on top of X11 in someway, so it was minimal. It was with the PostScript imaging model, but you still had the whole "send your PostScript program to the server." It's the same kind of thing.

Guy: The crown jewel is actually the imaging model.

David: That was my opinion. When I was at Adobe, I talked to a bunch of people about the notion that, "Why don't we have an imaging library instead of Display PostScript?" That's really what you want for the desktop.

Guy: It turns out it was a good idea.

David: It's a great idea, isn't it [laughs] ?

Guy: As the story unfolds, we'll hear more. So you're at RBI cranking away on stuff, and Apple is going down the drain and grabs onto the life raft that is NeXT. Then what happens?

David: At some point, it became a little bit of a black box to us because it just wasn't clear exactly what was going to happen with the way this is going to be put back together. We were starting to look at some of the printing code for the NeXT, essentially NeXTSTEP, OpenStep, or the NeXT OS. I don't know what it's called anymore. We were looking at that. It was very ancient kind of thing. I guess I'll forward a little bit and just say, "What popped out at all of these, even though Apple originally looked like they were going to stay with the Display PostScript route maybe with some extensions, is they decided, and I'm so thrilled that worked out just fabulously in my opinion, is they wrote their own imaging library that was based on the PostScript imaging model or the PDF imaging model by that point, and they called it Core Graphics or Quartz 2D."

I looked at that, and I'm like, "This is exactly what I was hoping would happen." I know better how it happened now because when Apple and NeXT merged, a bunch of really smart people from NeXT came over to Apple. At this point, the QuickDraw GX system was dead and gone. That was not going to happen. That had already been canned.

Guy: That was one of the things that Steve got booed on stage for when he gave that Q&A.

David: Is that right? I didn't realize that.

Guy: I'm pretty sure it was. It was OpenDoc and the QuickDraw GX.

David: I had remembered GX being gone before then, but I believe you. I didn't talk about any of the bets that I've made over my career. I bet against this PostScript. In the early '90s, I had a bet with a colleague at Adobe saying, "There's no way Apple is going to license Display PostScript from Adobe," and he said, "Oh, I'll bet you on that."

I said, "OK, well we've got to set a timeline on that bet. I can't say never. I've got to collect some time."

We made it two years. I won that bet, which was a burrito. My standard stakes. The funniest thing is when NeXT and Apple merged and it looked like Display PostScript was going to be Apple's new graphic system on the Mac, the same friend sent me a message. Of course, this was I don't know how many years later, maybe eight years later, "Hey, it looks like I'm right." No, you're not.

Guy: Out falls Quartz 2D.

David: Out of all of this falls Quartz 2D, which I think is just tremendous. The genesis of that is, well, the NeXT team comes over. I think, at that point, again I don't have the inside info on how that actually came about but, I think they pretty much realized Display PostScript is not what they wanted to be building on the Mac platform at that point. Even though they shipped the developer previews like you said, absolutely true. They wrote their own library. They built the imaging model using the imaging model of PDF/PostScript graphics and made it a client library, it's a light-weight rendering library. Peter Grafanino, who was one of the NeXT people that came over, he had been a graphics guy at NeXT. He was the person I remember people at Adobe working with, among others, on the NeXT software when they were doing Display PostScript.

Peter, who I think is just a super brilliant person. 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 work for us instead of work as contractors."

That's what we ended up doing. Not everybody, but most of the people on the team, came to Apple as employees in June of 2000.

We may earn a commission for purchases using our links. Learn more.