The Long View
Draw
In 1983, LisaDraw was a wonder to behold. Interactive vector graphics programs existed before the Lisa, but they were very specialized and dependent on expensive graphics hardware. As a graduate student in the 1970s, I used a crazy homebrew vector graphics system built using a Tektronix 4000 series graphics display, a Tektronix plotter, and a 300 baud connection to a the University of Colorado’s mainframe computer. It was pretty slow going, but it still seemed like a miracle. Reproducing it at home would have been expensive, to say the least. The most common non-research vector graphics drawing systems in the 1980s were computer drafting programs used by engineers. These ran on expensive equipment, and they weren’t very interactive. They didn’t use a mouse; line endpoints and polygon vertices were created by entering coordinates at the keyboard. Vector graphics in those days were printed onto paper using pen plotters, like the Tektronix plotter I used (or real big ones used by engineers). Those kinds of plotters could only draw vectors, not pixels. LisaDraw was a program like those drafting programs, but different. It couldn’t make drawings to precise scale, but you could draw and edit interactively using the mouse to drag endpoints and vertices around on the screen.. That was really great, but the mouse wasn’t the most startling innovation in LisaDraw. The most important thing was its integration into the rest of the programs. After you drew something using a computer drafting workstation, you could print it or view it, and that was it. After you drew something in LisaDraw, you could import it into other programs, like LisaWrite, and use it as a part of a compound document. In the early 1980’s, most people made compound documents by cut and paste, using real scissors, paper and paste.
When the Macintosh came out, everybody knew that a vector drawing program for it, called MacDraw, was coming. But it wasn’t actually available till near the end of the year, which seemed like a long time to wait. The September/October 1984 issue of MacWorld showed tantalizing screenshots from a prerelease version of it. It looked a lot like LisaDraw. When MacDraw was released, Apple reps gave it away at Macintosh User Group meetings, and it was everything you hoped it would be. In addition to matching LisaDraw feature for feature, the Macintosh designers went the Lisa one better. They designed a format for graphics that could be used variously to represent a drawing that could be rendered automatically on the screen, sent to the printer, saved as a resource that could be stored in the resource fork of a program or document, or used as data that could be stored in the data fork of a document.
At runtime, data in this format was called a Picture. Resources or files containing data in this standard format were called PICT. The two graphics editors provided by Apple, MacPaint and MacDraw had their own native file formats for storing their documents, but they could also save their data in PICT format. MacDraw supported the PICT format directly, but MacPaint, always unique, couldn’t save data directly as PICT. It required that images be exported using the clipboard or scrapbook. This was always a possibility anyway, because PICT was the format for graphical data stored on the clipboard or in the scrapbook. Any graphics program that could cut and paste graphics had to be able to convert it to PICT. And this was easy for programmers to implement. The Quickdraw graphics library included an easy way to create a Picture, and then print it, draw its contents on the screen, or save it on the clipboard, in a resource, or as a data file. You didn’t need to know the format used to encode a Picture, either to make one, or to use one created by somebody else. But the format was nicely documented anyway.
Making a PICT
The means for making a PICT were built right into Quickdraw. basically, the Picture format was just an encoded sequence of drawing calls made into the Quickdraw library. You told Quickdraw that you wanted to make a picture by making a call to OpenPicture. Any Quickdraw calls you made after that, which would normally draw into the current GrafPort (usually an on-screen window) would become part of the Picture instead. When you closed the Picture with ClosePicture, you got a handle to the Picture. The picture data were stored in that handle. If you wanted to draw the picture on the screen, you could do it by passing that handle to another system call, DrawPicture. If you just made a resource and associated it with that handle, it was a PICT resource. To make a PICT file, you just created a file, put a 512 byte empty header at the top of it, and wrote the data in your Picture handle into the rest of it. If the Picture was particularly large, it might be tricky to store it in memory, so you might stream it to a file instead, and there was an easy way to do that too. Reading a PICT in from a resource or file was just the opposite process, and so was easy too. Printing Picture data was a breeze. Basically, the printer driver looked like a GrafPort, and you could just draw your Picture into it, and it would be printed. Printer drivers were designed to read those data and turn them into an appropriate form for the printer. For the ImageWriters, this just meant rasterizing the image, and for LaserWriters it meant converting it to Postscript.
Pictures From Everywhere
Being able to draw an illustration in MacDraw was a huge benefit, but not all pictures are drawn by hand. The interchangeability of PICT data meant that new programs for working with pictures didn’t have to do as much. If you were writing a program that would make graphs from numerical data, your program didn’t have to handle every kind of detailed annotation you might think a user would need. You could save your graphs in PICT format, and they could be edited in MacDraw. Likewise for images from scanners, computer simulations, and a host of other programs whose outputs were images. If you had in-house software to acquire data and convert it into images, you didn’t need to make it all-purpose. Just get it, and write it to a file in PICT format. The user could bring it into MacDraw to do the rest. Once all the images were in MacDraw, line widths could be altered, typefaces and sizes adjusted to taste, fill patterns changed, etc. Because of this ability to bring a range of different kinds of images onto a single page, MacDraw became a great page layout program, especially for multi-panel figures of the kind used in scientific papers. Of course, this was before real page layout programs, like PageMaker, appeared.
Lots of Draw Programs
MacDraw spawned many competitors. Once you had seen what a drawing program should look like, it wasn’t that hard to make new ones. Some were specialized. There were computer-aided drafting programs, drawing programs designed for architects, landscapers, comic book artists, drawing programs for kids, etc. There were some that were more directly MacDraw competitors, like CricketDraw. Other programs that combined the functions of MacDraw and MacPaint were very popular. The two I used were Canvas and Superpaint. They were wonderful and popular, and became mainstays for several years. The key to all this creativity was the PICT format. It meant that if you could make a better drawing program, you could automatically get access to all the graphical data made by any other Macintosh programs, and if you were a Macintosh user, you could buy any drawing program you wanted without concern for compatibility with all your other programs. It was an enormously powerful idea, and many (about 5) years later was copied by Microsoft as the Windows Metafile format introduced in Windows version 3 and is extensively used in Microsoft Office even now. One of the key features of PICT (and Metafile) was its universality. There is a world of difference between pixel art and vector art, but they live together happily in the PICT file format. It was a natural for Canvas and Superpaint. Basically, all of these files were just PICT editors. They let the user create or modify commands to the Quickdraw graphics engine, and then let Quickdraw render the result on the screen. What you see is what you get was ensured by the fact that while you were editing it, it was being displayed to you by the same code that would display it anywhere else, including the printer. And printers were important then.
Printing
The biggest problem with the early Macintosh had to do with printing. Business computer users never used line plotters. They were completely dedicated to the use of daisy-wheel printers. These were really just typewriters that could be driven by a computer. They were called “letter-quality printers” because they made letters that looked like they were made with a typewriter, and businessmen considered only the typewriter to be “letter-quality”. That seems laughable now. I look at old letters and papers I wrote on typewriters, and they look terrible. Anyway, as dumb as it might have been, that is what people thought was best, and the Macintosh initially did not have a daisy-wheel printer available for it. Instead it had a very high quality (150 dpi) dot-matrix printer, the ImageWriter. I wrote letters and papers on the ImageWriter printer, some of which I still have, and they look great to my eyes today. It also could print images, and they also look great. But I couldn’t submit a manuscript for publication or a grant to a funding agency, if it was printed that way. They had rules against dot matrix printers. Why? Maybe just because the bureaucrats who made (and still make) rules like that were mindless lemmings who uncritically repeat the party line, whatever it happens to be at the time. That is definitely true. But maybe it was also because the dot matrix printers that were connected to IBM PCs made documents that looked like crap (even worse than letter quality). Could people see the difference between dot matrix printing done on a Mac vs a PC? Yes, but they didn’t understand what they were seeing, and you didn’t dare tell them, or you would run up against their mindless rules. Sometimes, I would xerox my ImageWriter copy onto typewriter paper, and submit that. If I used a typewriter-looking (monospaced) typeface, I could often get away with it.
The Lisa had a letter-quality printer. The Macintosh probably could have had one, but the LaserWriter was in the works. It was announced at about a year after the Macintosh rollout, but its coming was known around Apple much longer than that. Apple leadership knew that the LaserWriter would be a game changer. When people saw the output of the LaserWriter, they would never want a daisy-wheel printer again. But the LaserWriter was slow in coming and the absence of a letter-quality printer became one of the constantly-repeated mantra’s of the PC-wielding Mac-haters. which included most of the computer press. This is sometimes cited as one of the problems that led to Steve Job’s ouster from Apple in 1985. It is a believable story. If you had seen a LaserWriter and its output, would you be interested in investing in the development of a typewriter to attach to a Macintosh? Of course when the LaserWriter did appear, daisywheel printers disappeared and the term “letter quality” disappeared from use. The Macintosh became the vehicle of the desktop publishing phenomenon, and sales took off (at least in graphics departments, if not business offices). Jobs was already gone, and Sculley took the credit.
The LaserWriter was everything you wanted in a black and white printer. It made text way better than a typewriter. Better than most printed books and newspapers. But the LaserWriter could also print images at 300 dots per inch, more than 4 times the resolution of the computer screen, and twice the resolution of the ImageWriter. It was so great that the Macintosh print driver couldn’t make full use of its resolution. Maybe you didn’t notice it. You wouldn’t if you were just looking for pixelated (jagged) lines, because the LaserWriter drew lines from point A to point B at its full resolution. But the coordinates of point A and point B had to be specified at Quickdraw resolution, which was in integral multiples of 1/72”. The LaserWriter could print locations for line endings and polygon vertices to the nearest 1/288”. Likewise, Quickdraw could specify line thicknesses to integral multiples of 1/72”, whereas the LaserWriter could make lines as thin as 1/288”. There were a number of quick workarounds offered to programmers to try to make programs that could take better advantage of the LaserWriter’s capabilities. One good one was to just print everything 4 times too large, and then ask the user to scale the drawing to 25% in the print dialog. Later, Apple provided a special system call, prGeneral, which allowed you to query the resolution of a printer, and scale your drawing to make maximal use of it. It was welcome, and worked great, but it was not elegant. Elegant would be you draw the image into the printer’s GrafPort, and it automatically uses the full resolution available. And prGeneral didn’t help with PICT files or resources. If you wanted to export something as a PICT so it could be edited in a drawing program at LaserWriter resolution, you still had to export it way too big, and take care of scaling it in the receiving program. When the Macintosh II, and color Quickdraw arrived, there had to be version 2 of the PICT format that supported color drawing. Quickdraw coordinates were still integers, so the basic problem was not solved. A scale factor was included, which apparently allowed you to draw large and tell Quickdraw to scale the image down. But, except for Pict Detective, I never found a program that respected that scaling factor. In the end, the problem of Quickdraw resolution wasn’t fixed until Quickdraw GX was released in 1995. And it never got much use. Things had already gone bad by that time.
The LaserWriter spoke a different language from Quickdraw, and specified locations on the page as floating point numbers. If I could specify the coordinates of my vector graphic in floating point numbers, it would print at the maximum resolution of the printer. New printers would have higher resolutions. My graphic would get better automatically as this happened without any effort on my part. No doubt about it; the LaserWriter’s language was better.
Postscript
The Postscript printer language was truly revolutionary. This was because it wasn’t a printer language at all. At least not in the same sense as other common printer languages, like Hewlett-Packard’s popular but hobbled PCL, which most PCs used to communicate with their printers. Postscript was a general purpose computer language, and a really cool one. The LaserWriter was a complete computer designed by Burrell Smith, the same guy who designed the Macintosh hardware, but instead of a screen, it had a print engine. It had a serial port on it, and you could connect a terminal to it and just start entering commands, consisting of code written in Postscript. Postscript looked and worked a lot like Forth, which was a popular programming language at the time, and so it was easy to get started with it. But you could also use Postscript commands to print. One of the guys in my Department in Memphis wrote a Postscript driver and print server for a PDP-11, connecting the computer to the printer via its serial port. The PDP-11s were laboratory computers that were still in common use in 1985. His software allowed any PDP-11 on our homemade serial network to print text documents or graphics written in Postscript. The LaserWriter was expensive (about $7000!), but it could be shared by a lot of low print volume operations like us. The PDP-11 thing was pretty cool, but there was a much better way to share a LaserWriter among Macintoshes -- LocalTalk. A department that usually needed a printer for every computer could get away with one LaserWriter used by everybody. And anyway, computing cost more then than it does now. A PDP-11 laboratory computer cost about $10,000 in those days, and a Macintosh Plus cost about $2500. Over time, LaserWriters got cheaper. Pretty soon, just about everybody (I mean every Macintosh user) was printing on a Postscript printer. It was great, but we weren’t using it to full capacity trying to run it from Quickdraw and PICT.
Of course, the new Postscript features were only available when printing, and only had to do with print documents, but at that time print was the ultimate goal of all graphics. There was no world wide web, and there were no LCD projectors. Everything had to ultimately make its way to print. We couldn’t stand to let advanced Postscript features go unused when preparing drawings for printing. So Apple provided the opportunity to send Postscript code directly to the printer from your program. Quickdraw included a command called PictComment that allowed for extension of the language by inventing new directives and embedding them in Picture (and PICT) information. They didn’t do anything when drawing on the screen, but they could be interpreted by a program when it read Picture data into memory, or .... by the print driver. So Apple added to the Postscript printer drivers the possibility of just embedding Postscript code in line in the Quickdraw data sent to the printer. The driver would suspend interpretation of Quickdraw commands, and just send the raw Postscript commands to the printer. That opened up the capabilities of the printer, but it broke the symmetry between screen, disk file, and printer. You could put PICT data containing inline Postscript on the clipboard or scrapbook, but the receiver of that probably couldn’t interpret it. A big part of what was great about Macintosh graphics design was going, and it wouldn’t be coming back.
Or You Could Just Draw in Postscript
In the meantime, Steve Jobs and NeXT were preparing their new operating system, and adopted Postscript as its universal language for drawing on screen, storage in files, and printing. A Display Postscript clone was developed by Sun Microsystems to use in their operating system. Postscript was taking off, and moving away from the Macintosh. It would not be possible to completely rebuild Macintosh graphics around Postscript. But the beauty of the unified graphics model was something appreciated mostly by programmers. Users only saw the outer facade. Maybe, all that was needed was a good Postscript editor. Something like MacDraw, only instead of reading PICT-related files, it could read and write Postscript. Postscript was just a programming language, written as plain text. What if there was a program that could read that stuff, render it on the screen, and allow it to be edited, then pass it directly to the printer? Maybe it wouldn’t be compatible with other drawing programs. Maybe that wouldn’t matter to people who needed to work with Postscript, and who were unhappy with the other drawing programs anyway.
Maybe it makes some sense that Illustrator didn’t take over the graphics software world right away. Programs like Canvas and Superpaint continued to add features, and attract users. Their ability to edit both line and pixel graphics set them apart from all the earlier programs, and they were faster and prettier than Illustrator to use. One of the competitors was another latecomer, and another program that was a little different--Freehand.
Freehand came out in 1988, one year after the first version of Illustrator. It had a lot in common with Illustrator, including the use of splines as elements of drawing, and also a preview and outline mode (although you could edit in both). Freehand had its own file format, but could read and write encapsulated postscript files. And Freehand could exchange images with Quickdraw-based programs using the clipboard and scrapbook. Freehand would evolve in parallel with Illustrator for years. They eventually became each other’s only serious competition. Freehand won every careful feature for feature comparison every made between the programs, and experts all agreed that Freehand was a superior program. Still, Freehand is gone now, along with Canvas, Superpaint, FullPaint and all the others, and Illustrator stands pretty much alone. What happened? I don’t know. It didn’t happen with paint programs. Today, Photoshop still rules the high end, but there are a host of very capable programs in that category, and new ones appear all the time. In the drawing category, there are very few alternatives to Adobe Illustrator. There are a couple of specialized programs, and there are a couple of not very capable X11 programs.
Whatever happened, it occurred at the end of the classic Macintosh era. Freehand was the only serious competition for Illustrator when OS X took off, and there was a carbonized version of Freehand that worked on OS X. Freehand had a lot of serious fans, and would probably have survived if it had not been acquired by Adobe for the expressed purpose of killing it off, to remove the last serious competitor to Illustrator. Of course, that was sick and wrong, and none of us will ever see Adobe as the good guy again. But before that happened, it was clear that vector drawing program market was not growing like the rest of the software market. I think it was just the democratization of the software market. Drawing stuff on the computer is work, and is usually done as a part of a job. Computers have gradually shifted from the hands of people using them for work to people using them for play. Everybody takes pictures, and if it is easy to do, lots of people will think it is fun to modify them. Many people want a good photo-editing program, which is what paint programs have mostly become. Few people, even professionals, need to edit vector art. Plotters (that required vector art) and printers (that encouraged it) are disappearing. Many images are being prepared for the web. And the web doesn’t like vector graphics.
A PICT Equivalent for the Web
The growth of the interwebs has discouraged vector art. If you are creating web content in Postscript, you either offer it as a download (in pdf) or you make a rasterized version of (Save for Web & Devices…) and post that. Why is that? It isn’t to reduce bandwidth. Up to some limit of complexity, vector graphics are more compact to define than pixel graphics. We don’t have it, but the web needs the equivalent of the PICT format -- a single image markup language that can handle vector graphics, pixel art and text in a single format. Of course, web designers realized this a long time ago. The compact size of vector graphics was recognized early as a benefit for bandwidth-intensive web graphics, like animations. Jonathan Gay, a legendary Macintosh programmer who wrote the classic Dark Castle games for Silicon Beach, and who added Postscript support to Silicon Beach’s classic program SuperPaint, wrote a vector graphics drawing program called IntelliDraw, back in the days when people were still doing that. Although great, IntelliDraw did not succeed, and Gay decided to write a vector drawing program called SmartSketch for a pen-based operating system called Go. Go also failed, and in the mid 1990’s Gay converted SmartSketch into a conventional vector graphics program for Macintosh and Windows. It was expanded to include animations and renamed FutureSplash. It (and John Gay) were acquired by Macromedia, and the program’s name was shortened to Flash. Adobe got it at the same time it got Freehand (some say Flash is what Adobe really wanted). Flash has been very popular and successful for animations, but never became a general purpose graphical format for the web, and Flash is supported on the web by a plug-in, that has to come from Adobe. Flash is so huge, and tries to do too much. It is really overkill for pictures that don’t move and don’t make sounds.
A better candidate for the web’s PICT equivalent is called Scalable Vector Graphics (SVG), and it was introduced in 2001. That’s only a couple of years after Flash. It has been argued about, worked on, and extended for 10 years, but it hasn’t actually been used very much. There are full versions, partial versions, and mobile versions of the specification. The SVG working group (as of this writing) includes members from Microsoft, Google, Cisco, Samsung, Apple, Adobe, and nearly everybody else who should be in it. So what’s happening? Well, the biggest problem for the past 10 years has been that SVG is not supported by Microsoft Internet Explorer (through IE8). You can make SVG graphics in a bunch of editors (including Illustrator), and you can post them on your website... and nobody much will ever see them. There has long been plug-in’s available for SVG, but somehow they didn’t get installed in everybody’s browser, the way that flash did. But maybe there is some reason to be optimistic. WebKit browsers, like Safari and Chrome, can handle a subset of SVG features. The latest version of Internet Explorer (IE9) has some support for SVG. There are SVG plug-ins for browsers, some of which have been discontinued recently, maybe because of increased built-in support for SVG in browsers. Try your browser out. Can you see this?
No? How about this?
Tuesday, June 28, 2011
