Page Layout is a Dead-End Street

For a good laugh, try walking into a public library and asking if they have books that discuss the relative scratchiness of Ewok and Wookie fur. Of course, the laughter will be theirs — as they throw you out the door — because even if there were a book that explored this arcane subject, it would take nigh-on-forever to find it.
OK, now how would you find this subject on the Web? You might search AltaVista for “ewok wookie fur scratchiness” or type “How scratchy is Ewok fur?” into AskJeeves or Excite. But any seasoned Web-searcher will tell you that you’ll be lucky if you find an answer in any reasonable amount of time.
The problem: There’s just too much information out there, and while it’s easy to search for specific words or phrases, it’s relatively difficult to search for meaning.
Meaning is what XML is all about. If you’ve recently been sipping margaritas under a rock, XML is “extensible markup language,” and it looks kind of like HTML except that instead of saying what a bunch of data should look like (like describing the look of a Web page), XML describes what a bunch of data means. Once you have assigned meaning to content, you can specify rules for how that content should appear, depending on the medium you’re using.
Driving Down a Dead-End Street
Today, laying out a page in QuarkXPress, Adobe PageMaker, or Adobe InDesign is like driving a car down a dead-end street: It’s easy to do (though some tools let you get to the end of that street faster than others), but once you reach the end of the street, what can you do with your content?
Right now you have three options:
- Exporting all your text from a page layout in ASCII or MS Word format is like disassembling the car, carting the pieces to another street, and trying to put it together somewhere else.
- Exporting your content or even the look of the page as HTML is like driving in reverse until you get to the nearest intersection where you might be able to turn around.
- The PDF format is like trying to make a U-turn, then putting your car on top of a flatbed truck and driving that around. No, there’s just no good way out once you’re facing a dead end. But that’s about to change.
The Next Generation of Publishing
While I don’t always agree with Quark’s position or vision, I am convinced that they’re doing something spectacular with QuarkXPress 5.0 and Avenue.Quark (yes, that’s really the name of the product) — they’re opening up the dead-end street and turning your page-layout program into just another stop along the way to wherever your content is going. The key is that they’re separating your content and the form it takes.
The trick is XML: By tagging text with XML, you give it meaning. Now you’ll be able to tell QuarkXPress how to translate meaning into form. For instance, once you tag a paragraph as a “first-level headline,” you can tell XPress to make headlines look like one thing when building a printed page, something else when building a page for the Web, and even more different when the headline appears on an e-book.
If this sounds like style sheets, it’s because the concept is basically the same: Assign a name to text (or graphics or whatever), and then change the definition of that word to suit your needs. The difference is in scope. Suddenly all your content can be tagged, and those tags can move from one program to another — into XPress and out again to be used someplace else. (Even, in theory, into future Adobe products.)
Giving Your Computer Eyes
One of the most exciting offshoots of XML is the Scalable Vector Graphics (SVG) standard, which lets you describe artwork and page geometry in the XML “language.” SVG will let you export not only your content from your applications, but also how the content looks. This might seem like a total contradiction to everything I’ve just been saying about separating content and form, but remember that you can choose to use or ignore all those tags later.
Note that both SVG and XML are public standards, and in fact Adobe and many other companies appear to be just as excited about them as Quark. SVG is written in XML, but not all XML-aware programs will be able to deal with it.
Here’s a few things you should be able to do with SVG:
- Export an entire page from your page-layout program (even your plain ol’ page not built with XML) and reproduce it in an SVG-aware Web browser.
- Search a database of the past issues of your magazine for “every story that was printed in an oval-shaped 20%-cyan box with a 2-point black frame in the past year.”
- Import vector Web graphics onto your pages, converting them to native page objects that can be edited.
- Build interactive buttons and other special effects using vector art (which is extremely compact) instead of raster art (which clogs up bandwidth).
In many ways, SVG may exponentially expand what you’ll be able to do with a next-generation page-layout or illustration application. Best of all, because XML and SVG are open standards, in theory everyone will be talking the same language, again freeing your content from the dead-end-street syndrome.
Brute Force versus Elegance
Plenty of folks have been taking about “cross publishing,” using the same content in multiple forms. But Quark’s idea of “media independent publishing” goes even further, where content and form are fully separate, and your documents can shape-shift depending on the medium and the message.
Of course, if only Quark were heading in this direction, I’d hardly care. Fortunately, a lot of people are looking toward this media independent future, where images, text, and rich media can be pulled from servers anywhere on the planet and given form based on intelligent rules, which are — in turn — based on meaning written in XML.
OK, maybe no one really cares about the relative scratchiness of ewok and wookie fur, but the not-too-distant future — in which data actually means something — is rich with possibilities, from powerful searches to flexible publishing.
This article was last modified on March 10, 2025
This article was first published on April 18, 2000