by Jeff Clites <online@mactech.com>
As you've probably heard, Apple's new graphics system, Quartz, is based on PDF. You've seen screen shots of Quartz, and undoubtedly you've encountered PDF documents before, but that's probably where your knowledge of PDF ends. While you really don't need to know anything about PDF in order to develop applications for Mac OS X, it always helps to know a little bit more about the technologies you are working with, so that you can fully leverage them in developing your products. This month we are going to take a closer look at Adobe's PDF and its role in Apple's new imaging system.
So what is PDF exactly? The acronym stands for "Portable Document Format", as you probably know, and it is fundamentally a file format. In fact, Adobe's description, stated at the beginning of their PDF Reference Manual is, "PDF is a file format used to represent a document in a manner independent of the application software, hardware, and operating system used to create it. A PDF file contains a PDF document and other supporting data." This is in stark contrast to PostScript, which is a full-fledged programming language. So at first blush it may seem a bit strange to base a graphics and windowing system on a file format-Apple refers to PDF as a superset of PostScript, but now this seems somewhat like calling Photoshop a superset of C++. So what's the deal? Things begin to make a little more sense when you learn that PDF (and specifically, a PDF file) has four conceptual parts: a set of basic data types, a file structure, a document structure, and a page description. It is this last part, the page description, which is the core of PDF-as-a-graphics-model.
PostScript and PDF are based on the same conceptual imaging model, sometimes called the Adobe imaging model. At the most basic level, this model is no different from that of QuickDraw or most other 2D graphics systems: you create an image using operators which move a virtual pen to place marks on a canvas. In PostScript, you have primitive marking operators and in addition you have programming constructs such as loops and variables. In PDF, you retain these basic marking operators (and add others), but without the additional programmatic infrastructure, so a PDF document ends up being a description rather than a program. As a simple example, a page with 30 circles on it might be created in PostScript by placing the circle-drawing instructions in a loop which iterates 30 times; in a PDF file, this would be represented by 30 separate circle descriptions. As a consequence, a PDF document is potentially larger than a PostScript document, but it doesn't require the overhead of an interpreter to draw a page, it can render faster because the primitive marking operators are implemented directly in machine code, and it is easier to manipulate because strings and other components can be reliably located within a document (in PostScript you really have to "execute" the entire page first). You can think of this aspect of PDF as a RISC version of PostScript.
So, basing Quartz on the Adobe imaging model really means basing its primitive marking operators on those of PDF (and consequently of PostScript). These operators live in the part of Quartz called Core Graphics Rendering. (I'll call this "CG" for short, as Apple seems to have not officially named their new graphics model. I'll avoid just calling it "Quartz", as this includes Core Graphics Services, which is essentially the window server.) As I mentioned above, there isn't a huge conceptual leap from QuickDraw, but that doesn't mean that there aren't huge advantages. For one, distances in CG are given as floating-point numbers rather then integers, and can be in real-world units such as inches and centimeters. This difference is profound, as it largely divorces the drawing process from explicit concerns of screen or printer page size or resolution, and reduces such things to primarily a scaling issue. It's also fundamentally vector-based, so you're not tempted to draw a single "pixel", although even in QuickDraw one tends to do this by drawing a 1 x 1 square. Also importantly, CG has a sophisticated set of text layout and graphics transformation operators, so finally it will be easy for a Macintosh programmer to rotate text and images on the screen. And on top of PDF's core, Apple has added features such as composition and translucency. It wouldn't be surprising if these were to migrate back into a future version of the PDF specification. (Also note that CG is based on PDF 1.2, rather than the current version 1.3, but Apple plans keep pace with the Adobe's specification as it evolves.)
Core Graphics Rendering serves as the hub of drawing activity, accepting instructions using its native C-based API (which you'll likely access through a higher-level framework), QuickDraw commands, PDF files, or possibly other input sources. From here it can render them to the screen, create raster data for a printer, or record them in a format such as PDF or PostScript. (It's fairly trivial to record a sequence of CG drawing operations to a PDF document, much as a PICT could store a recording of QuickDraw commands. It's easy to forget that PICT is actually a vector format, isn't it?) Note that this doesn't mean that all graphics, before displaying to the screen, exist as actual PDF documents.
There are several key advantages to this arrangement. First, it brings the conceptual simplicity that Display PostScript brought to NeXT's operating systems, namely a single graphics model for both screen and printer. This makes things such as print preview and print-to-file trivial, since PDF is the default spool-file format. This also means that you can get perfect output from cheaper, non-PostScript laser printers, and it opens the door for a new generation of "dumb" printers with minimal computational power, because the operating system fundamentally understands how to render documents all the way to raster data at printer resolutions. (This is a tactic used by the first generation of laser printers produced by NeXT, which were cheaper and operated at a higher resolution than other printers available at the time, and which I'm excited to see finally make it to the Macintosh. It always seemed like a waste to pay for a slow processor which sits mostly idle in a printer when there is a much more powerful processor available in your computer.) Core Graphics has many technological improvements over Display PostScript, but it also has the very clever advantage of freeing Apple from Adobe's licensing fees and restrictions while maintaining a very similar API which allows long-time OpenStep developers to leverage their past experience.
In the coming months I hope to cover additional aspects of Mac OS X's new graphics environment. Until then, you have some reading to do. First and foremost, you should read Apple's Inside Mac OS X: System Overview. In fact, you should read the whole thing, from cover to cover, and then read it again, because it's all important information that you'll need to know as we move forward with Mac OS X. There are also several articles on the Ars Technica web site which augment this same material, including an article specifically on Quartz and Aqua. Second, take a look at Adobe's PDF specification - it's large but fairly readable. You won't have to know this information directly in order to use Core Graphics, but it helps to know a little bit about PDFs in greater depth, since you'll be working with a lot of them. This reference also spells out the connection between PDF and PostScript more fully. If you're interested, you might also do a little light reading on PostScript, mostly for perspective rather than for the details. Adobe's PostScript Language Reference has a great deal of explanatory material, and you can also download the electronic version of Glenn Reid's Thinking in PostScript book, which is much shorter. (Somewhat ironically, even the PostScript references come in PDF form.)
