Before you plunge in, you should know that there are a few things missing from this review. Beta software, by definition, is not ready for release. Before it is released, bugs are fixed, features are added, and, sometimes, features are removed. Reviews of pre-shipping products are a bad idea in general because readers tend to make purchasing decisions based on reviews, and if shipping products differ from the reviewed beta, it can cost someone money. Consequently, Quark VS InDesign.com has a policy of reviewing only full shipping, retail software. That means no pre-release or beta versions and no trial software—even if it’s supposedly feature complete. If we’re going to give you an opinion you might factor into your buying decision, then we have a responsibility to only evaluate and opine about the exact product you might buy, as you would buy it.

So, if the policy against beta reviews is such a hard line rule, why are you now reading a review of the QuarkXPress 7 public beta? Because, beta though it may be, QuarkXPress 7 is important. Whether to use XPress or InDesign is a crucial question for publishing and design workflows all around the world. It’s a fundamental question for billion dollar publishing empires, and, in many ways more importantly, it’s a sink or swim question for the smallest creative studio. In lean times and highly competitive creative industries, revolutions have to be anticipated and taken advantage of the moment they begin to build momentum. And, if a crucial technology is on the decline, as XPress has been the last four years, signals of its demise are even more important to those whose livelihoods depend in some way on that technology. XPress 7, even in beta, is important to our readers because, if it’s the wave of the future, they need to be riding on top of it. And, if it’s a falling stone, they need to know to get out from under it.

XPress 7 is important, and that’s why I reviewed it in beta. Because it’s in beta, you must remember that everything below—the good, the bad, and the ugly—is subject to change before the product ships. And, because the product is beta, there are a few things missing from this review.

First, there is nothing about native Photoshop PSD document import and effects, although this represents some of XPress 7’s most talked about selling points. I didn’t write about them, because they aren’t there; the current public beta of XPress 7 does not contain a PSD import filter. When the beta was released in January 2006, Quark acknowledged that PSD import was absent from the program, which is why it—and any features predicated on it—is absent from this review. You won’t find a review of Quark’s Web features either. This was a decision I made because of the lack of PSD support; I want to cover a complete Web creation workflow, and PSDs are typically part of that workflow. You also won’t find performance statistics here. Except in two key instances, I don’t mention how long it took XPress to perform different tasks or well it performed on the computers with 1GB of RAM versus those with 2GBs. While I did measure XPress’s speed under various conditions, that data is effectively irrelevant. More so than anything else, performance and response speed change throughout the beta cycle. It would be a disservice to you, the reader, if some statistic I mentioned about the beta’s performance influenced your decision to purchase a shipping version that performed differently..

For thirty days I put the XPress 7 public beta through its paces, building or recreating real world projects representative of what most people expect to do with a desktop publishing program—and a few things they shouldn’t expect but will do anyway. Except as above, I tried to cover in depth every new and updated feature of XPress 7. Consequently, this is a very long article—even for me. I’ve organized it with multiple headings to help you read what interests you while easily jumping over what doesn’t. If you’re unconcerned with the details, you’ll find my conclusions and buying advice on the last page.

Let’s start with first impressions, then we’ll get into the nitty-gritty of the good, the bad, and the ugly of the QuarkXPress 7 public beta.

That New Quark Smell

Upon initial launch, the truly astute will note the new Composition Zones Tool on the toolbox. Other than that new 16×16 parcel of pixels, XPress 7 looks exactly like XPress 6.5. Looks are deceiving.

The XPress user interface has always been a double-edge sword for Quark. It hasn’t changed significantly since version 3 in the early Nineties, leading many users to describe it as "tired," "out of date," and even "decrepit." Regardless of the new features added with each release, the static user interface is as much responsible for consumers’ belief that Quark doesn’t innovate as the average half decades between full version releases. On the other hand, the lack of major changes in the user interface and most often used features equate to instant proficiency—if you were productive in QuarkXPress 3, 4, 5, or 6, you can start cold with XPress 7 and be just as productive.

Quark is once again betting on familiarity to grease the upgrade path. While that decision will ease the transition for those who find themselves forced to upgrade, retaining the 15-year-old user interface will undoubtedly cost Quark market share among those who equate interface changes to feature innovation.

If your testing of the XPress 7 beta stops at opening the application and creating a new blank document, then all you will see is the same old XPress. Don’t stop there.

Start working with XPress 7—create a box or line—and you’ll get your first whiff of that musky-sweet new Quark smell.

The Good

The Measurements Palette
As ever more functions and options are incorporated into applications, software makers are increasingly challenged with finding places to hold the necessary controls. No one will argue that, as valuable and convenient as palette-accessible options are, palettes are quickly becoming too numerous and unweildly in the average application.

The XPress solution to control clutter has historically been variable content—or context sensitive—dialog boxes like Modify, whose selection of tabs holds several times the number of controls in the same space through the use of tabbed panes. The selection of tabs in the Modify dialog changes according to the currently active tool and selected object or objects. Dialog boxes, however, have an inherent limitation: When they’re open, you can’t access the layout or select objects. The versatility of palettes is that they are always onscreen, enabling simultaneous access to controls and objects. Of course, that leads to palette bloat.

Context sensitive palettes, like the XPress 6.5 Measurements palette or Illustrator’s or InDesign’s Control palette, compromise by presenting different controls based on current tools, tasks, or selected objects. Although efficient to a point, these solutions have never gone far enough. In InDesign, for example, the Control palette presents character and paragraph control options only when the Type tool is active, but, as any InDesign user knows, control over text formatting can also be exercised when text frames are selected with the Select or Direct Select tools—but not with the aid of the Control palette. Character and paragraph controls are hidden from the InDesign Control palette until the Type tool is selected. There isn’t a way to change Control palette modes manually, which is the only thing holding the Control palette back from completely replacing several floating palettes.

XPress 7 bridges the gap between the application’s idea of what controls are relevant and the user’s. The Measurements palette is still context-sensitive, but you can now manually change between any of its nine completely different modes on the fly through tabs at the top of the Measurements palette.

By default, the mode tabs bar is hidden, appearing only when the mouse rolls over the palette. I liked the tabs so much I set them to always show with a simple right-click on the Measurements palette title bar, which, incidentally, is another way to toggle the visibility of the other floating palettes.

All the most common tasks, formerly only available in the Modify and Attributes dialogs, are now distributed through the different modes of the Measurements palette. The ability to change text box insets, change frame borders, and adjust runarounds all on the fly, without time-consuming dialog boxes, are phenomenal productivity enhancements. If your layout experience is limited to XPress, the ability to see your objects and the entire page as you do things like set and change tab stops will have you grinning like a Cheshire cat.

If you’re worried about fingers programmed through years of XPress suddenly fumbling without the need to constantly press CMD+M (CTRL+M) for Modify, CMD+SHIFT+F (CTRL+SHIFT+F) for Formats, and CMD+SHIFT+T (CTRL+SHIFT+T) for Tabs, rest easy, friend: The dialogs are still there, and the keyboard commands haven’t changed. They’re just no longer necessary.

Space/Align
How much could Quark possibly improve something as straight forward as Space/Align? You’d be surprised.

In previous editions of XPress, spacing out or aligning multiple objects was, like most other actions, accomplished through a dialog box. Items could be distributed or lined up horizontally relative to their areas, centers, or left or right edges, or vertically relative to their areas, centers, or top or bottom edges. The exact space between them could be specified as well, of course. How the aligned or distributed objects related to the page was not something with which XPress concerned itself. XPress 7 takes that part more seriously.

Rather than the familiar Space/Align Items dialog, XPress 7’s Measurements palette has—you guessed it—a Space/Align mode. Instead of the multi-step process of selecting radio buttons and menu items before objects move, the new method is much faster and familiar: just click an alignment or distribution button. All the usual options are there, as well as a new Page Relative Mode that lines up or spaces out the selected objects relative to the page’s edges and/or vertical and horizontal centers. Want to put an object dead center on the paper? Forget about doing the math—just click a button the Measurements palette.

With this new functionality comes one sacrifice: You can no longer specify the amount of space between distributed objects unless Page Relative Mode is enabled. Thus, it’s not possible to distribute a selection of objects across an entire spread in a single step. All things considered, it’s a more than equitable trade-off.

XDraw
One of the biggest and furthest reaching changes to XPress 7 is the new XDraw screen rendering layer, which actually runs off the graphics engine of the host operating system—GDI+ on Windows and Quartz on Mac. XDraw finally brings to XPress an acceptable level of confidence in the relationship between onscreen work and output. If you’re new to XPress, it may come as a shock that now is the first time in the 20 year history of QuarkXPress that it has had WYSIWYG.

In past versions, any serious for-print work required numerous printed proofs or at least printing to PDF where Acrobat would substitute for what XPress should have had all along. There simply was no reliable way to work on the details of a design—especially those involving images, small type, or tight clipping paths—without printing, and working from, a proof.

Now, XPress’s display is not only as accurate as other applications, it’s gorgeous. Moving around even shadow- and transparency-laden layouts is smooth and stutter-free, the document window updating faster than I could have dreamed.

Drop Shadows
Been there, done that, right? Heck, InDesign has had drop shadows since CS. XPress is just playing catch up; nothing new to see here, right?

Wrong.

Photoshop’s drop shadow control is the gold standard by which all other applications’ implementations of this very popular feature are weighed. XPress 7’s is not up to that standard—and shouldn’t be, it’s not an image editing application. It isn’t a duplicate of InDesign’s method for creating drop shadows either. While many new XPress features can’t be compared head-to-head with InDesign’s, drop shadow creation and control is easily compared. Both applications bring their own style to the feature, and both come closer to Photoshop’s method in their own ways.

In InDesign CS2, drop shadows interact with objects behind them using blending modes such as Multiply, Color Dodge, Color Burn, Luminosity, and twelve others. Shadow controls include setting opacity independent of the object casting the shadow, separate X and Y offsets, blur, spread, and noise, which, when used judiciously, can enhance the realism of drop shadows. The color of the shadow may be chosen from swatches pre-created on the Swatches palette, or mixed with RGB, CMYK, and Lab sliders. Once the Preview box is checked, all changes effected in InDesign’s Drop Shadow dialog provide instant feedback with live previews.

XPress 7’s Drop Shadow is also in a dialog—Modify—but it has a Measurements palette mode, too. The Measurements palette mode is much faster than Modify, which lacks a live preview. There are only two blending modes—normal and multiply—which limits the effects possible with this feature to drop shadows or simple outer glows. Use the multiply mode when the drop shadow is darker than the objects behind it. This will keep the darker shade, whether that belongs to the shadow or the color beneath, while lighter shades are discarded. In normal blending mode (multiply off), the color of the shadow is directly blended with the colors of objects beneath—the preferred method when your shadow is anything but black.

In addition to the blending modes, there is an opacity slider for controlling the shadow opacity, and an option to force the shadow to inherit the opacity of it’s host object—in other words, if the object is 50% transparent, the shadow will be too, even if the shadow is specifically set to be 100% transparent. This is a cool feature because it enables shadow opacity relevant to its host object—as one is made more or less solid, the other updates to match. Another nifty option Quark saw fit to include was the ability to knock the shape of the object out of the shadow. With an opaque object, this toggle has no effect. But, if the object or any of its colors are partially or fully transparent, you have the option of choosing whether the drop shadow shows through. Think of a text box that has no fill, but it’s drop shadow still doesn’t show inside the area of the box itself.

Shadow positioning controls are where XPress 7 and InDesign really diverge, each having its strengths and weaknesses. In XPress, a skew field enables the creation of a rudimentary cast shadow, something InDesign can’t do. In fact, not even Photoshop can do it better than XPress without a third-party plug-in. A shadow blur control in XPress doesn’t stand up against InDesign’s spread, noise, and blur options. Neither does the single distance measurement, which controls how far a shadow falls from an object’s top left corner (the “origin”). Between the angle and distance controls, you have all the same freedom as InDesign’s independent X and Y shadow coordinates, but it takes more practice to get the get same result in XPress. However, the presence of one tiny checkbox in XPress makes the effort more than worth it: Synchronized Angle.

If you’ve used the drop shadow layer style in Photoshop, you should immediately understand the purpose and convenience of this feature. Checking Synchronized Angle on several objects keeps the angles of those objects’ shadows identical, creating the illusion of a single light source affecting them all. Changing the shadow angle on any such object automatically changes them all—a huge time saver. Although Photoshop has this option (called Global Angle there), InDesign doesn’t; InDesign’s drop shadows are not linked in any way, and the Drop Shadow dialog box resets to default options every time it’s used on a new object.

Runaround can also be set to account for a drop shadow. By default, runaround only applies to an object, ignoring a drop shadow, even if that means text overlapping the shadow. Often times, that’s desired behavior, but when it isn’t, XPress 7 provides the option of forcing text to runaround the shadow as well as it’s host object—this is something InDesign can also do, but only by manually editing the shape of the text wrap (A.K.A. runaround) bounding box.

One major drawback I found with XPress 7’s drop shadows is that, on screen, shadows are not necessarily accurate representations of the printed output. Toggling the Multiply Drop Shadow option, for example, which determines whether the shadow’s blending mode is set to multiply or normal, shows no difference between them on screen. Printing the two modes, however, reveals significant differences in the way background object colors blend through the shadow. It could easily make the difference between a believable composition, and a collection of objects. This could be a costly gotcha on press.

Which one does drop shadows better—XPress or InDesign? That depends entirely on the shadow you want. In one case, XPress is better, InDesign in another. Keep Photoshop handy for those times when you need more than either can offer.

OpenType Support
I won’t go into a lengthy definition of OpenType fonts. If you don’t know what they are by now… Well, then you’ve probably been using XPress. Perhaps I should give a brief definition.

Succeeding the legacy of both PostScript Type 1 and TrueType fonts is OpenType, a Unicode (double-byte) intelligent font format capable of holding all the world’s currently active—and even yet to be created—written languages—and much more—in a single .OTF or .TTF font file. PostScript and TrueType fonts only have space for 256 characters per font, which is extremely limiting and led to inconsistent assignment of slots—one font may use slot X to hold a trademark symbol, while another font may stick a virgule in slot X and insert the trademark symbol somewhere else. With OpenType’s generous number of slots, every glyph has its own predefined place that is, and must be, consistent across all OpenType fonts; if a type designer intends to draw a trademark symbol, it may only be placed into slot X and nowhere else. Similarly, if the type designer decides not to draw a trademark symbol, that slot must be left empty.

Even after filling up the OpenType slots with all Western language glyphs and their various accents, ligatures, and symbols, then doing the same for Chinese, Japanese, Korean, Arabic, and other languages, there are still many, many slots available. Consequently, those slots are tasked with holding other sorts of glyphs, like alternate versions of letters and symbols. It’s possible, for example, to find a single font file incorporating not only one complete set of upper- and lower-case letters, but also a genuine small caps set—drawn at small caps size, with stroke weights matching caps and lowercase glyphs—as well as titling alternates, swashes, several different styles of numerals (e.g. separately drawn fixed-width, variable width, numerator, denominator, superior, and other styles), and many, many other glyphs. Where Type 1/Type 3 or TrueType fonts required several font files to provide all of the above—with the attending difficulties of typesetting lines of copy in multiple fonts—a single .OTF (or OpenType version .TTF) file can now handle it all.

Now that you understand some of the value of OpenTypes to a professional publishing workflow—and it’s important to recognize that the above is a significantly abbreviated description—you should know that XPress can finally use them in version 7. OpenTypes can be used with earlier versions of XPress, as long as the operating system understands them, but they’re treated like TrueTypes in those earlier versions; it isn’t until XPress 7 that you have access to the features and benefits of OpenType fonts.

OpenType fonts are fully cross-platform—gone is the need to fear character substitution, text reflow, and other common issues of collaborating between Windows and Mac. The same OpenType font works—and works exactly the same—on Mac, Windows, and Unix. During my testing of XPress 7, I transferred XPress projects and their fonts between Windows XP and OS X several times. At no time did a single letter of any text box reflow, nor did any symbol or accented character suddenly turn into something else.

In OpenType support, XPress is most certainly playing catch-up. To put it in context: even Photoshop, an image editor, laps XPress 6.5 in typesetting power. Making good use of OpenType required a rewrite of XPress’s text engine, which took time. Now that it’s done, XPress is finally back in the game of professional grade typesetting. It does not yet support every feature of OpenType—and not as many as its competitors—but in a single bound it catapulted from the Stone Age into the modern world.

So what’s still missing? Certain contextual OpenType features that change glyphs on the fly (if activated), such as changing the second instance of the letter e in a word to a different version of the e for variety, aren’t fully supported. They work on simple occasions, but become less reliable as the complexity of contextual replacement increases. Stylistic sets are also missing.

Fractions are handled in an odd way, too. OpenTypes have spaces for the most common fractions—1/2, 1/4, 1/3, and so on—as single glyphs, much like Type 1 and TrueType fonts. They also have slots for all 0-9 numerals drawn as numerators and again as denominators and the instructional coding necessary to build fractions from those glyphs. Unlike the pre-drawn fraction glyphs, built fractions consist of at least three glyphs inserted and kerned to create the appearance of a single fractional glyph. In English, that means the fraction 5/9 would be created from the 5 numerator glyph, a solidus (slash), and the 9 denominator glyph. In some cases, XPress 7 bypassed the pre-drawn common fractions like 1/2 to build them using the three-glyph method. Whether this is an issue with the beta or intended that way is not known. It’s a minor point, regardless.

Because of the way XPress reads and interprets OpenType fonts, they may appear in the typeface menu with slightly different names than in other applications. This is a choice XPress is making about which internal font name and ID fields to read and use. There are several fields, with different types and lengths of font titles and IDs, and XPress chooses them differently than some other applications. It’s worth mentioning here because it can be disconcerting or even frustrating if your fonts look out of order on a menu. (For a third method, look at the font menu in Microsoft Word.)

While XPress has the customary quirks and is missing a few useful OpenType features, it does support the majority of OpenType—certainly the most commonly used features. For every one thing XPress 7 does wrong or oddly in this area, it does ten other things absolutely right.

Via the OpenType menu on the Measurements palette (in Character Attributes mode), you have access to ten different major OpenType features, four styles of general numerals, and four styles of special numerals (superscript/superior, subscript/inferior, numerator, and denominator). Depending on the font, some, none, or all of these features may be available. Those wrapped in brackets are unavailable because they were not included in the font—not all OpenType fonts include all the features. Script fonts, for example, rarely have a need for more than a single type of figure.

Among the potentially available OpenType features are: standard ligatures (fi, ff, fl, etc.); discretionary ligatures (ct, st, ch, etc.); scale-appropriate ordinals (1st, 2nd, 10th, etc.); titling alternates, alternate versions of glyphs for use at larger sizes; all small caps to convert a mixed case arrangement of letters to genuine small caps; small caps, which converts all lowercase letters to genuine small caps; fractions to convert any typed fraction (e.g. 1/12) into a proper set of numerator, solidus, and denominator, and; contextual alternates, which, similar to ligatures, searches for arrangements of glyphs that would be more aesthetic or readable using alternate versions of some of its constituent glyphs (e.g. replacing the second g in jiggling with a smaller-tailed version to increase readability).

OpenType options can be applied anywhere you can apply other text attributes—selectively to highlighted text, or as part of character style sheets, which, of course, can be incorporated into paragraph style sheets. I recommend you set your default Normal character style sheet to an OpenType, and turn on standard ligatures so you won’t have to manually set this fundamental option. Depending upon what kind of type you normally set, you may want to add other OpenType features to your default Normal character style sheet as well.

Setting aside every other new feature of XPress 7, true support for OpenType fonts and most of their capabilities is the single biggest step Quark could have taken to bring XPress into the modern world of typesetting. It has a few issues (noted below under the “The Ugly” section), but, in the case of OpenType, the scales are overwhelmingly heavy on the what-they-got-right side.

Glyphs Palette
With OpenType support comes a new Glyphs palette for getting at each font’s roughly 65 thousand potential glyphs. It’s very similar to InDesign’s, but that isn’t a knock against XPress—it’s just an effective solution. This—in XPress 7—is what a Glyphs palette should be. I won’t say it’s perfect, but it’s close.

The complete set of glyphs in any installed typeface and style can be viewed in its entirety. When the viewed font is an OpenType with extra embedded features, subsets become available, including: small capitals, discretionary ligatures, historical forms, lining figures, stylistic alternates, swash, or anything else defined in the font. Loading Adobe’s Minion Pro Med OpenType into the Glyphs palette, for example, will yield 19 individually viewable glyph subsets. XPress’s Glyphs palette also includes pop-ups of glyph variations included in some OpenType fonts—for instance, all the different versions of a lowercase a, all compiled onto the flyout menu accessible by clicking and holding on any one a. If it’s in your font, the Glyphs palette makes it easy to access. Once found, double-clicking any glyph inserts into the current text box at the cursor position.

XPress also uses the Glyphs palette in an interesting new way. Instead of placing commands to insert symbol, space, and break characters on a menu or leaving it up the user to find glyphs (many of which are effectively invisible) inside individual fonts, the Glyphs palette includes a couple of global glyph sets. Loading one such set gives instant access to commonly used type marks and symbols such as the trademark, registered trademark, copyright, and dagger symbols, as well as the middle dot bullet, ellipsis, and em and en dashes (if present in the font). Other global glyph sets assign visual indicators or icons to such things as breaking and non-breaking versions of a hair space, 6-per-em-space, em space, flexible space, and indent here, discretionary hyphen, and discretionary new line markers. Placing these items on the Glyphs palette is a fantastic idea and incredibly convenient, although I do wish XPress also allowed the user to assign keyboard shortcuts to the most common symbols, spaces, and breaks. Fortunately, you can manually find glyphs you use often just once, and then add them to the Favorite Glyphs area, which is handily always in view at the bottom of the palette.

The special breaking and non-breaking spaces and markers are extremely useful, but the list is far from exhaustive. Missing are the usual complement of story-level breaks, such as column, page, and odd- and even-pages, and layout-level dynamic characters like page number, next page number, and previous page number. The last three are in XPress, but buried on the new Utilities > Insert Character menu. All of the other special characters and spaces on the menu are in the Glyphs palette, making it much more likely users will forget—or never find—the menu.

Font Fallback
Font Fallback, currently included in 6.5 but largely ignored, is enabled by default in 7. Font Fallback is XPress’s method of dealing with missing glyphs. For example, without Font Fallback, importing or pasting copy that uses glyphs not present in the current font will beget familiar empty boxes. With Font Fallback enabled, however, XPress searches for an active font that does contain those glyphs, automatically replacing the white boxes. How do you know you’ll get the same glyphs—that a registered trademark symbol won’t be replaced by an umlaut? Well, you don’t, unless you use OpenType fonts. OpenType fonts have a specific and inviolable position for every assigned glyph. Only an A is allowed in the slot assigned for the A; if an OpenType font doesn’t include an A—a symbol font, for instance—then the A slot must be left empty. This is the rule and law of OpenType font development. XPress 7’s new Unicode support for OpenType fonts means Font Fallback will move through the list of active fonts until it finds one with a glyph in the correct slot; OpenType means that that glyph must be the one intended for that position—the A in this case.

Use OpenType fonts whenever possible, and think of Font Fallback as your safety net against falling through empty type boxes.

Color Level-Transparency
Next to Composition Zones and OpenType support, XPress 7’s promise of color-level transparency has been the most eagerly anticipated feature of this new release—perhaps even ahead of all else. Knowing a little about how difficult it is to get software to affect transparency and flatten it correctly for print, I had strong doubts Quark could pull it off the first time out of the gate. XPress 7 would be a good first effort, I thought, but they wouldn’t get it right until version 8 or 9.

I was wrong.

Color-level transparency is, in most cases, more accurately thought of as attribute-level transparency. Opacity doesn’t work like tints; you can’t create a 50% transparent blue swatch any more than you can make all instances of blue across all types of objects 50% transparent in one fell swoop. Instead, you manipulate the opacity of colored attributes of objects.

Given a standard picture box, the opacity of both the box’s frame and background colors are independently adjustable. The box can have a 25% opaque background color while the frame is 75% or 100% opaque. Simply change the opacity percentage beside the Tint field on the Colors palette. And, even with transparency applied to the box’s attributes, box contents remain wholly opaque—unless you change them too.

Select the Picture Color button on the Colors palette to reveal that it too has an opacity setting. Want a colored gel effect on a photograph? Don’t take it back to Photoshop; just color the picture box background and reduce the opacity of the picture itself. Text, too, can be rendered partially or wholly transparent—and on a per-character basis. The next time you have a headline that trails off into the distance, really trail it off with diminishing opacity!

Wait. Here’s the best part: It prints.

And, oh, boy, is it fast! In 45 seconds XPress 7 printed a transparency-heavy document while InDesign required nearly three minutes to print a comparable document. Subsequent tests produced similar speed gaps on both Mac and Windows computers.

Flattening is handled in the updated print dialog, and is just a simple matter of choosing the output resolution for rasterization. XPress rasterizes on the fly and hands the flattened document off to the printer. When you would rather XPress didn’t handle the flattening internally, a simple checkbox in the print dialog outputs the document with transparency intact.

Knowing that color-level transparency was the big, important XPress 7 feature in the minds of most designers, I planned to test it in round after grueling round of production-level conditions, ferreting out every nuance of the feature—the good, the bad, and the ugly. Then, I knew, I would write extensively about my experiences. It would become the centerpiece of my review. My editorial about all the other new features would drop hints about transparency, building up to the climax of the deepest coverage possible on XPress 7’s color-level transparency. But, I can’t turn this into a centerpiece—there isn’t even enough to the feature for a decent hook!

I ran color-level transparency through all it’s paces; I produced the projects I intended. I printed—a lot. I made PDFs. Then I printed the PDFs. I tore the PDFs apart to see how XPress flattened transparency. I even recreated in XPress 7 some of the projects I had previously built in other applications—not just layout applications but drawing programs, too. I did all that, but it’s not worth reporting the details because nothing went wrong, and nothing revolutionary happened. It. Just. Worked.

I wish I could say more, but this is such a direct feature that there’s nothing more to say. It works exactly as Quark said it would, and exactly as any designer would think it should. Pick a background, frame, picture, or text color, change it’s opacity, print, go home for the night. It’s uncomplicated and unassuming. The only thing revolutionary is the fact that there’s nothing more to it. It just works—and it’s seriously cool.

Blend to Transparency
Where color-level transparency is the most accurate description is another feature of XPress 7 you simply won’t believe until you try it for yourself: solid-to-transparent blends (a.k.a. gradients). Certain drawing applications have had the feature for years, but some still don’t. Moreover, no other layout tool can do it.

Blends are made the same way as in previous versions of XPress—on the Colors palette. Choose your blend type, and then pick your two colors. The difference now is, you’re no longer stuck faking a blend to transparency by dropping tints down to 0% (solid white or paper color). Beside the tint field is a new Opacity field. Merely type in an opacity percentage or drag the slider, and objects behind that color’s side of the blend will pop into view through the blend. You can’t even do this in Illustrator without the extra work of building opacity masks!

Alpha Channel Masks
Alpha channels have long been supported for determining clipping and runaround areas. However, they’ve always been treated as no better than common clipping paths—one-bit transparency, 100% there or 100% invisible. Now that XPress supports truly transparent objects, alpha channels, with their full range 256 levels of opacity, are used to vary the visibility of images.

Let’s say, for example, that you have a portrait atop a transparent background. In Photoshop, you feathered the stray wisps of hair—some strands are even 25, 50, or 65% opaque to enable realistic blending the background. Photoshop automatically creates an alpha channel to store this opacity data. Placing that image into any earlier version of XPress, with its limit of one-bit support for clipping, would have left a solid color halo in the feathered areas. In 7, however, simply open Modify, and, on the Picture tab, choose the alpha channel embedded in the Photoshop document. Ta da! Now the image blends in XPress exactly as it does in Photoshop, with feathered edges and 25, 50, or 65% opaque strands of hair.

Alpha channel masks are also independent of object-level transparency—an alpha channel mask can be handling internal opacity variations while XPress is making the entire picture 50% more transparent.

Single Layout Mode
XPress 6 introduced the metaphor of projects—multiple, distinct or related layouts in a single document. One project could, for example, contain an entire identity package across several layouts—a business card layout, letterhead in an 8.5×11-inch layout, #10 envelopes in a third layout, and so on. Both print and Web projects could happily co-exist in a single project, with all layouts in the project represented as tabs at the bottom of the document window. Projects are, of course, a very cool concept. Throwing in Synchronized Text made the project-layouts metaphor a big step forward in document production.

Apparently the tabs were something of an inconvenience for some XPress users when working with single layouts. So, in the New Project dialog of XPress 7 is a new Single Layout Mode option, which hides the tabs unless you later insert another layout from the Layout menu. A preference setting toggles whether Single Layout Mode should be the default.

Append
If you enviously read the previous section about multiple layouts in one project, thinking about your catalog’s twenty different documents and wishing you would have known about that option last month, rejoice. XPress 6 may have introduced the project-layout metaphor, but XPress 7 takes it to the logical next step (several next steps, actually; keep reading). In addition to importing style sheets, colors, H&Js, and all the usual items from one XPress project into another, Append now appends layouts, too. Got a folder full of related .QXP files that should be together? Just open XPress 7’s Append dialog from the File menu, grab your first project, and select Layout from the list. All available layouts in the project will appear in the first list to the right. Selectively append them, or click Include All to append all layouts at once. XPress automatically resolves conflicts with identically named layouts by prefixing a non-unique layout name with an underscore.

NOTE: It has been reported in other media that the Append (Layout) function will actually insert pages from one project (.QXP) into another layout—for example, adding project A’s 10 pages to project B’s 10 pages to result in 20 contiguous pages. This is not the case, nor, I have been told, will it be so in the shipping version of the product. Appending layouts is just that—appending one layout into another project; it is not appending pages.

Next: Job Tickets and Job Jackets

Job Tickets and Job Jackets
In the old days before desktop publishing, the term “style sheet” referred to all typefaces, colors, and other stylistic choices required by a project. Multiple jobs for one client or project were produced from the same style sheet to ensure consistent style. A job ticket was the project specs—do this, in this format, output to this proof, output to this substrate, and so on. Job tickets included deadlines, client contact information, where assets could be found, and a tracking system—usually signatures of who did what on the job.

Since the advent of software like XPress, many terms have been redefined. “Style sheet” has come to mean merely the definition of text style, and “job ticket” now means what style sheet used to.

XPress 7 includes reusable, sharable job tickets that, similar to XPress document templates, contain all the style sheets, colors, H&Js, output setups, and other definitions of a project’s style and function. Job tickets can be created and passed out to clients for approval. Even better, they can be created in-house, then e-mailed to vendors who work with your brand, ensuring consistency without having to fax over a printed list of the typefaces, sizes, and signature colors for your organization’s documents. Any layout in XPress—print or Web—can be assigned a job ticket, optionally overwriting any conflicting or altered styles or colors. They’re like Append, automated. Best yet, should style definitions change, using a job ticket instantly brings projects and layouts back into compliance with revisions. This is a big plus for any production manager or creative director.

More complex projects may have several different but related specs. For instance, one ticket that handles printed documents may specify PMS colors, the use of custom-built, corporate fonts, and an output style to a particular ICC profile. The same client may also employ a second, separate job ticket for Websites and enewsletters, using closest-match Web-safe colors and a selection of Web-safe fonts. Those multiple job tickets can be assembled into a job jacket, which functions sort of like a super job ticket—one file, with multiple definitions (job tickets) within. Creatives simply attach to their layouts the right tickets from the jacket.

Being perhaps the world’s biggest fan of anything that infuses automation, efficiency, and consistency into the creative workflow without sacrificing creative freedom, I absolutely adore XPress’s job ticketing and jacketing implementation. Short of the weekly church bulletin, I can’t think of a single publishing workflow that wouldn’t benefit from job tickets and jackets today… Come to think of it, you should be using for your church bulletin, too.

Composition Zones
One document:one user. Big publishing solutions broke the 1:1 ratio long ago, but it has persisted as the rule in sub-$5,000 desktop software. Recognizing the need for collaboration in medium and even small publishing, both Adobe and Quark have pursued ways to transition into a one-to-many, one document:many designers workflow. Editorial programs like Quark’s QuarkCopyDesk and Adobe’s InCopy opened the door halfway, allowing many editors to write copy into one design layout, but the one designer:one document barrier remained.

XPress 7 breaks down that barrier with composition zones. Similar to editorial solutions, layout designers apportion sections of a page for use by someone else on a different computer. These composition zones are saved as separate documents other users open and edit. Designer A works on the rest of the layout, leaving the zone as a hole. Simultaneously, Designer B works only that hole, without even seeing the rest of the layout.

Creating composition zones is simple: With the new Composition Zone tool, drag a rectangle to define the composition area, then define its sharing options on the new Shared Content palette. Zones can be named for easy reference, and optionally shown as additional layout-like tabs at the bottom of the project window. They can also be defined as internal, which retains the 1:1, document:designer, ratio, or saved to an external .QXP project file, allowing one designer to work in the original layout while another works on the composition zone. In a stroke of genius, composition zones can be made available to not only the current project, but to multiple projects—reusable designs or layout segments that can be designed once and incorporated into any number of layouts. It’s this feature that makes composition zones valuable to the single-person workflow. By making the shared zone available to multiple projects, changing the design once updates all projects and layouts using it. Put simply, it’s like linking to the same image in multiple layouts; but that image can be one or more picture boxes, text boxes, rules, stars—anything that can be placed or drawn in an XPress layout.

From within the new Collaboration Setup dialog the frequency and type of shared content updates can be specified (as can job ticket and jacket linking). Shared content may be set to only update at opening (like linked images), before output (like linked images), or even at intervals while you work. Automatic updates take a little getting used to; while typing a photo caption on a mostly empty page it can be jarring when the entire page suddenly fills with text and imagery.

Did I mention you can also share an entire multi-page layout with any number of projects, just like a composition zone?

Composition zones and shared layouts are fantastic, but, of course, there’s room for improvement.

Specifically, it would be nice if Designer B had the option of seeing the entire layout, even if it’s locked to him. Designing ads on a periodical page, of course, is better handled double-blind, but not so in most other instances. Rarely do different sections of the same page exist autonomous from one another; there is usually some coherence between the work of different designers on the same page. I would also like to see shared content differentiated from full projects on disk somehow. Saving a zone as an external file creates a .QXP project file, which, when looking at a folder full of XPress project files, looks like a full layout. Inevitably, someone will get confused and overwrite or delete a composition zone or the full layout file with the other. If XPress gave external shared content a different file type and extension, or even suggested a naming convention like “shared, page 2, of issue 9 project…”, it would help alleviate the confusion. Currently, XPress just offers the default filename of “Layout 2”, “Layout 3,” and so on, just like the Save dialog.

Compared to what shared content is and can be, these are extraordinarily minor complaints, and they should in no way detract from the fact that composition zones and shared layouts are the future of collaborative creative publishing. XPress 7 paves the way into that future almost flawlessly. Bravo!

Split Windows
Zoom in to tweak a detail, zoom out to see the effect on the whole object, zoom back in for more tweaking. It’s a familiar dance to anyone who works on complex or visually-rich designs. Take a load off: the dance has finally ended.

XPress 7 now supports multiple views of a single project—including all of its layouts—although it works a little differently than you may be used to in other applications. Rather than spawning a completely new copy of the document window, which can then be resized and repositioned autonomously, XPress splits the current document window either horizontally or vertically. And, you can keep on splitting.

Wait, it gets better.

Each window/view has its own independent view settings. Sure, you can zoom in on the details in one window while watching the whole page in another window, but you can also have a third showing the in-RIP separations, a fourth with a grayscale proof, and yet another showing process and spot colors.

Proof Output
Combined with split windows, XPress 7’s new proof output views are a pre-pressman’s dream. After configuring the new color management engine in XPress’s Color Setups > Source, layouts can be soft proofed live onscreen in any of seven modes: grayscale, composite RGB, composite CMYK, composite CMYK and spot, convert to process, process and spot, and in-RIP separations.

And those are just the defaults! New output setups can be created (from scratch or by editing a duplicate of one of the defaults) with a standard, ICC profile-based color management interface. Moreover, setups are shareable.

The Not So Little Little Stuff
Get Picture and Get Text are no more. Now they’re the more logically titled Import Picture and Import Text, respectively. The keyboard shortcut of CMD+E/CTRL+E remains, though.

Those foolish layer indicator icons are gone, thankfully. Color coding layers is nothing new, but until XPress 7, boxes on any layer but the default included an awkward and often in the way layer icon in its top right corner. XPress 7 took a cue from other layer-enabled applications and dropped the icon. Now the color of object bounding boxes matches the color assigned to the layer—a vastly improved method.

Lock Story is a very handy little option for just about anyone who works with text. It does exactly what it sounds like: It locks out copy changes to the content of a text box. It even blocks Find/Change operations; copy can still be found and highlighted by Find/Change, it just can’t be changed.

Live, high-resolution image previews. ‘Nuff said.

When saving a page as an EPS fonts can finally be embedded, which suddenly makes XPress-exported EPS usable outside of XPress.

When text oversets, XPress 7 can automatically flow it onto to new pages. While it will only save your butt on the rare document without a fixed page count, it has a less obvious benefit: Scrolling through a layout looking for that little red overset text indicator is tedious and error-prone, but how likely are you to miss whole pages?

In versions past, replacing images in a picture box caused all previously applied attributes and transformations to disappear. For example, maybe you imported a low-resolution FPO and rotated it 45-degrees. Upon importing the actual image, replacing the FPO, the rotation would reset, as would any other transformations you may have applied. In the XPress 7 import picture dialog, however, is the Maintain Picture Attributes box, which, wisely, is checked by default. Replacing existing images retains all attributes applied to the box—scaling, rotation, even positioning. If you depend on XPress for image-heavy documents like catalog or member directory work, this a not so little little thing should have you jumping up and down right now.

Drag N’ Drop from the Desktop. On Windows (sorry Mac users), both image and text files may be dragged from the Desktop or an Explorer window and dropped into pre-drawn boxes in the XPress layout. This works for every file type XPress can import via Import Text or Import Picture, and it’s a whole lot faster.

Group Effects: To set fill, frame, or transparency options on multiple boxes at once, group them. When two or more boxes are grouped, either the Measurements palette or the Colors palette can be used to affect the attributes of all grouped boxes.

Picture Effects (a.ka. QuarkVista) now works on the raster content of EPS files as well as TIFFs. Changes made to a synchronized picture box will apply to all the other synchronized picture boxes—a very handy time-saver.

The Print dialog has been reorganized into a more logical, easier to use layout. On its Transparency pane are two simple options: A toggle to ignore transparency flattening and send any transparent areas through unflattened (and thus, maintaining their transparency), and a dropdown list to determine the resolution at which flattened areas of transparency will be rasterized. My only complaint with this is that, with transparency so new to XPress users, the function of these options is not immediately apparent. Before XPress 7 releases, I hope Quark uses the copious negative space on this pane to offer uninitiated users a definition of flattening as well as tips for achieving optimal results in common output scenarios.

Output styles can be saved for various media, including outputting to print, PDF, EPS, and PPML.

PDF/X-1a and PDF/X-3 standards are supported for output, and XPress 7 will even check your document as you work for objects and attributes not PDF/X-compliant.

Palette arrangements, including size, position, and whether the tabs show atop the Measurements palette, can be saved as palette sets. Those sets can even be given keyboard shortcuts for rapid switching.

The convenience of setting tabs from the Measurements palette is something you simply can’t appreciate until you do it.

Enhancements to tables include: splitting tables across multiple pages, with repeating headers and footers, odd/even row and column selecting for rapid formatting, dynamic cell resizing as you type, and auto-fit tables to imported data.

Next: The Bad of QuarkXPress 7

The Bad

The Measurements Palette
I love the vast improvements to the Measurements palette, but would like to see them taken yet further. First, all the usual one-object limitations of dialogs still apply to the reborn Measurements palette. You still can’t, for example, select multiple boxes and set their runarounds simultaneously. Without the need to open the Modify dialog for each instance, setting runaround is a faster process, but it could be much faster if the Runaround tab didn’t disappear as soon as more than one box is selected.

Another improvement I’d like to see to the Measurements palette is to make it dockable to the top or bottom of the application window. Maximizing a document window still means moving the Measurements palette out of the way of the scrollbars and layout tabs, which can be nettlesome.

Floating Palettes
The XPress 7 method of grouping palettes is clunky and counterintuitive. Multiple floating palettes may be stacked into a vertical group, which makes them movable as a unit. Even better, all palettes in a stack can be rolled up into a single, tiny title bar, or even closed with a single click. This is, of course, a very important feature for laptop users or anyone with limited screen real estate (and who he thinks he has enough?). Once they’re stacked, 7’s palettes are wonderful; it’s the act of getting them stacked, in the desired order, that’s awkward.

To attach palettes to one another, you must right-click (CTRL-click on Mac) the title bar of the intended upper palette and choose from a popup menu the name of the palette to attach beneath it. Repeat the procedure to attach each subsequent palette to the bottom of the whole stack. New palettes are only appended to the bottom of the stack; they must then be dragged up or down to rearrange their order, which isn’t obvious when the starting point is a menu.

Quark claims XPress 7’s menu-driven palette stacking is superior to Adobe’s method of dragging palettes toward each other’s tops or bottoms to stack. I disagree. The Adobe method provides more immediate control and visual feedback—a bold line appears to indicate the point of attachment before committing to it. Additionally, Adobe applications allow multiple palettes to occupy the same space on screen through tabbed grouping, something XPress 7 doesn’t have.

I do very much like the fact that different palette arrangements—including stacking order and sizes—can be saved as sets accessible with keyboard shortcuts. InDesign offers the same keyboard access to saved workspaces, but that feature is buried in the Keyboard Shortcuts dialog. XPress also lacks a default palette arrangement or set—move and resize the palettes, and there’s no way to get back to the default.

Quark may have a long way to go toward finding the most efficient method of managing palettes, but so do Adobe, Corel, Apple, and Microsoft. No one has found the magic formula yet, and I’m glad Quark is trying.

Origin
Very close to winding up under “The Ugly” section because of its ongoing requirement for needless pen-and-paper calculations is the continued lack of an object proxy in XPress 7. All positioning and sizing data is still relevant to the top left corner of objects—the “origin.” While this may be comforting to those who worried about the appearance of any similarity to InDesign or PageMaker creeping into in XPress 7, it’s profoundly disappointing to those of us who want to focus on laying out pages instead of stopping to crunch numbers.

The proxy—a representation of an object’s center point, four corners, and four sides, usually located near the transform controls on the Control or Transform palettes, and enabling positioning and sizing relevant to any of the object’s nine coordinates—has been a standard part of XPress’s competitors for more than 15 years. Quark should have incorporated a proxy or other means of controlling object positioning and size relevant to different corners and sides—at the very least the center point—years ago; finding it still absent from XPress 7, which has advanced in so many other ways, is profoundly disappointing.

Master Page Items
Master page items are still fully—and too easily—selectable on document pages. An errant flick of the wrist can still move or delete a master page item—or, worse, leave an extra, slightly out of place copy on the document page when the master page is reapplied.

Master Page Layers
Layer support on master pages has been a long hoped for relief from the ease with which master page items may be altered. Unfortunately, that relief is still nowhere in sight.

Inconsistent Measurement Field Entry methods
Many measurement fields still require typing in new values while others includes sliders, dropdown menus, and other alternate input methods. I would like to see more mouse-driven controls added—or at least used consistently—including up and down arrows beside fields like the X and Y coordinates, and sliders or dials added to fields like the drop shadow’s angle.

Palettes Refuse to Hold Positions
Between sessions, palettes move. They don’t go back to their default locations, they just move—usually to the bottom of the screen. This happens regardless of whether you have saved a palette set. The Measurements palette also doesn’t remember the state of the tab bar; whether you set it to always show or always hide, it reverts to its default behavior of appearing when the mouse moves over where it should be. (Although the palettes moving is annoying, the animation that accompanies the move is pretty cool—even on Windows.) This behavior, more so than just about anything else, smells like a bug. Hopefully Quark will stamp it out before the retail release.

The Not So Little Little Stuff
Layouts may be named, but those names don’t translate to the Save dialog. It would be just a little extra touch of convenience if XPress automatically entered the name of the first layout as the project’s name during the first save. Microsoft Word and Photoshop take this little user-friendly step, and it would be nice if XPress did, too.

When using the Split Windows feature, a fresh set of layout tabs appears at the bottom of every pane. These tabs enable not just multiple views of one layout, but views on all layouts in the document. The tabs are quite handy when working on related layouts, but use up far too much valuable screen space when working in a single layout. If that one layout is the only one, you can hide the tabs and reclaim some of the space by activating Single Layout Mode, but that won’t help if there are several layouts in the project. There should be a convenient way of hiding the tabs for split views.

There are no new text composition features. InDesign still holds the title of World’s Best Composer by a long shot with its hanging punctuation, optical character spacing, and multi-line paragraph composition. In fact, Illustrator boasts more advanced text composition than XPress. As a small redemption, XPress enables editing of kerning and tracking tables, which InDesign does not.

The Ugly

While some areas of the interface have been updated, others really show their age, smacking of the untamed System 7 and Windows 3.1 days. Even something as simple as the New Layer button on the Layers palette, with its stick figure-esque icon, shouts utilitarian after thought, not planned user interface. Why can’t XPress be both functional and attractive? I would very much like to see the XPress interface updated to modern standards of application design—I’m not necessarily talking about Adobe’s interface here. Both Apple and Microsoft have established guidelines for common interface elements such as default buttons, rollover buttons, and icons, and just a simple update to modern OS X- and Windows XP-style buttons and icons would hint at the next-generation publishing features under the XPress 7 hood.

Undo
Undo still won’t rescue you from the mistakes you really want to back out of. Saving and inserting, removing, or rearranging pages still cannot be undone with a flick of your fingers.

Locking
Object locking has been improved, but to what degree depends on your perspective. In previous versions of XPress, locking an object merely prevented it from being repositioned or resized with the mouse; it was still fully susceptible to any and all other modifications. Locked boxes could still be selected, and then moved or resized by changing the values in the measurement fields on the Measurement palette. They could also be altered in any number of other ways, including the application of fill and frame colors, changes to runaround settings, sent backward or brought forward, and their contents edited. In XPress 7, however, locked boxes can no longer be repositioned or resized using the Measurement palette, but everything else still works: their fills and frame colors can be changed, as can runaround settings and their stacking order relevant to other objects, and their contents are still editable.

As I noted under “The Good” above, text inside boxes can be locked, but that only prevents copy and color changes; text inside locked stories inside locked boxes can still be modified in numerous ways, including column options, insets, baseline options, and rotation of text.

XPress 7’s object and story locking is not what I think of as “locked.” Locking something should make it totally, utterly, wholly untouchable until and unless deliberately unlocked. As documents become more complex—and with the newfound ability to composite in XPress, the layers of complexity will pile up—it’s important to provide a facility for total box and content protection. Working on the middle object in a stack of ten is much easier when upper objects can be rendered unselectable. The old bring & send routine is just that: old. Moreover, it’s risky—did I press CMD+F5 five times or six?

When content is frozen, it should be frozen, without the constant risk that a distracted, tired, or less fastidious production intern will accidentally change a designer’s work. The Layers palette can help in some such situations, but not all and often not without unnecessarily increasing both the complexity of the layout and the job of working in it.

The Icon
It would be remiss to overlook the ugly Quark application icon. Is a yellow traffic light truly the best harbinger for XPress 7 Proceed with caution! May stop at any time! Fortunately, the application itself is strong and stable, because brand identity is not Quark’s strongest point.

Glyphs Palette
If you are accustomed to the extraordinarily useful shortcut of typing a font name into the typeface box to activate that font, one quirk of the XPress 7 Glyphs palette could drive you up a wall. You can indeed type the name of a font into the typeface box, and, like any Adobe, Macromedia, or Microsoft application, XPress will auto-complete the name as soon it recognizes it. However, if you enter the name of a font that is not installed, XPress will beep and popup an error message. Trying to clear the erroneous font name can be frustrating because every time you type or delete a character, XPress searches again—and errors again if the font isn’t found. Clicking away from the Glyphs palette also spawns the error, as does attempting to click the typeface dropdown list or highlighting and deleting the name entirely. The only way to clear the beep-prompt-click OK loop is to type the name of a font that XPress can find—which may take some time.

Type Style Buttons Not OpenType Compatible
Since time immemorial, XPress has included style buttons beneath the typeface menu on the Measurement palette. Experienced XPress users understand that using some of these style buttons carries with it an inherent risk. Sending bold or italic type through a RIP generally requires the presence of a bold- or italic-style font file, which is a completely different set of font outlines than the normal or Roman style of the same typeface. Heedless of this requirement, pressing the Bold style button on the Measurements palette will beget bold text—even if no bold-style font file exists. XPress will fake bold by thickening stroke weights, and it will fake italics by slanting text. Similarly, XPress has always faked superscript and subscript by scaling characters and adjusting their baseline offsets, as well as faked small caps by capitalizing text and scaling it down a user-specified percentage (usually 70-85%). The net result is just text set at a smaller point size—baseline alignments are usually off, and, more importantly, the stroke weights of the affected glyphs don’t match those of surrounding text. Often the difference is so profound that you might as well be using different typefaces entirely! Unlike faux bold and faux italics, these faux styles don’t cause problems on-RIP, they just create hackneyed type.

The behavior of the style buttons has not changed in 7: they still fake styles, even when used on OpenType fonts that include genuine superscript, subscript, superior, or small caps glyphs. (Underlining and striking through text is another issue, but I’ll let that go for now.) Clicking Small Caps, Superscript, Subscript, or Superior style buttons on the Measurements palette will not access those features of an OpenType font. Instead, you have to get to those features by clicking the green and black O OpenType menu on the Measurements palette and choosing styles one at a time. What could have been as easy as single click now requires two clicks and dealing with a menu. This is a true shame and a nuisance for designers who care about good type.

XPress 7 should encode the style buttons to first check that the active font is an OpenType, then look for, and use if present, the appropriate features within the OpenType font, and, finally, only fall back on the old faux methods if neither of the other two conditions has been met.

Another (relatively minor) issue observed in XPress 7 regarding OpenType support is that slashed zeros must be individually inserted manually via the Glyphs palette despite the fact that OpenType fonts have the capability of doing the substitution on the fly—if the application supports it, which XPress doesn’t.

Again, XPress 7 gets much more right with regard to OpenType than it gets wrong. The fact that it supports as much as it does on this, it’s first round with OpenTypes, is to be applauded. OpenType could be better, but it’s already very, very good.

PDFs
Native PDF generation via the JAWS PDF engine was added to XPress with version 6. Now, in version 7, it works. (That isn’t the ugly part.)

In version 6.x, PDFs failed more than half the time. XPress seemed to create them—and, indeed, a PDF would appear in the target folder—but nothing could read it, not even JAWS own PDF viewers. Often those PDFs that did open in viewers failed to RIP. Ultimately, XPress users universally reverted back to printing to Adobe PDF virtual printer, or to the old two-step method of printing to PostScript and distilling.

In total, I generated 52 PDFs from newly created XPress 7 projects as well as version 4, 5, and 6.5 documents opened into 7. Not one of the resulting PDFs failed to open in Acrobat. All ten of the ones I tried to open in OS 10.4.5’s Viewer also opened without issue. Further, the PDFs printed just fine—albeit very, very slowly. (This is the ugly part.) They printed slowly because the PDFs were massive. From one, three-page 1.2 MB XPress project, the exported PDFs invariably ballooned to 24.5-27.8 MBs. Larger XPress documents beget equally larger PDFs.

I ran through all the export options including preserving transparency, discarding transparency and flattening at various resolutions, using the standard PDF v. 1.4 (Acrobat 5-compatible) format, PDF/X-1a, PDF/X-3, and numerous compression settings. No matter what I tried, the resulting PDFs were gigantic.

This, is seriously ugly. The good news? XPress 7 is still in beta; there’s still a chance for Quark or JAWS to turn the beast into the beauty. Other than file size and lack of support for recent PDF 1.5 and 1.6 versions, XPress exports quality PDFs.

The Final Word

XPress 7 is a major new features upgrade, but many of the old frustrations linger. The same bad and ugly issues mentioned above are likely to remain parts of XPress for years to come—just as most have been in XPress for many years and versions already. There seems to be an internal struggle in the collective Quark mind between pleasing customers reticent to change, and advancing the state of the art for those who want to go further in their work.

Quark wants too much to placate customers who are resistant to change—which, in all fairness, represents a large portion of XPress’s current installed user base. Many XPress users have relied on the application for nearly two decades. They’re set in their ways, old dogs who refuse to learn new tricks and fight any attempt to advance the state of publishing. Ironically, these are often the same individuals who embraced XPress in the 1980s, when other old dogs stood firm on phototypesetters and manual paste-up. Publishing, in all its forms and parts, is an evolving, growing life form. Adobe invented computer-hosted soft fonts, not the process of putting type to page. Gutenberg invented the press, not the concept of books. Too much of XPress is being held back by a desire to please those for whom what they know will always be better than what they don’t know.

Within XPress 7 are several next generation technologies and tools, chief among them shared content, QuarkXClusive, color-level transparency, and job tickets and jackets. Support for OpenType fonts, alpha channel transparency, reliable onscreen proofing, and functional PDF export are catch-ups to current needs that other applications have been filling for years. XPress 7 should not have been the first version to deliver on these solutions. It wouldn’t have been if the innovative side of Quark’s mind was stronger than the side that wants to maintain the status quo. More importantly, 7 would contain fewer decades old pain points and frustrations if the innovation side were stronger.

The battle between XPress and InDesign is often characterized as a war of product development versus marketing. That’s rhetoric, regardless of which side utters it. History has born out the fact that Quark researches the current state of customers’ workflows, while Adobe asks customers directly what they want tomorrow.

Quark’s stated strategy “is not to focus on the feature sets of alternative products but on the current needs of our installed base.” The reason those “alternative products” have taken so much of XPress’s installed base is because they started fresh. InDesign was not an upgrade to PageMaker. InDesign was a fresh, new look at the current—and future—needs of the publishing and design industries. Adobe kept PageMaker alive, indulging the old dogs, for a reasonable period of time, then cut it off. Quark needs to follow the same path, starting fresh and building a whole new XPress to answer not only the current needs of its installed base, but tomorrow’s needs as well. And, they need to walk away from the things that keep the old dogs old and adaptable users away.

XPress 7 is a major step forward for both customers and Quark. It shows that the innovators within Quark know where they need to take XPress, and that they are gradually gaining strength and support. They must keep pushing. QuarkXPress 8 should be able to wipe away the entire Bad and Ugly lists.

Buying Advice
InDesign CS2 is still a superior product in many of the ways that count, but the list has grown significantly shorter. More importantly, XPress 7 is finally a strong stand that not only meets some of InDesign’s key features, it beats them.

If you are a QuarkXPress 3, 4, 5, or 6 user in a team-based periodical publishing workflow, the cost of upgrade—whatever it turns out to be—is worth it. Send Quark a blank check right now. Composition zones and shared content alone will bear out an acceptable ROI as they streamline your workflow. Editing kerning and tracking tables, OpenType, the Glyphs palette, QuarkXClusive, soft proofing, and output styles sweeten the benefits.

Those of you for whom InDesign CS or CS2 is the tool of choice in any workflow, switching to XPress is not recommended—especially if you happily converted from XPress. New XPress features like composition zones, color-level transparency, and the almost new Synchronized Text and multiple layouts are indeed a leap forward into the future of desktop publishing. XPress 7 also addresses many of the biggest problems with previous versions, but most of the old Quark quirks are still there. Diehard fans will feel right at home with their practiced workarounds. Those who threw up their hands and left XPress probably won’t be wooed back just yet.

Though, I don’t recommend switching from InDesign to QuarkXPress 7, I wholly recommend that the advertising industry, design studios, freelancers, and creative job seekers learn to use it alongside InDesign.

Quark has joined the battle now. In six months, the lines defining the territories held by these two powerhouse publishing giants will not be as clearly defined as they are today.

For some workflows, XPress 7’s new features and updates make it the clear application of choice. For others, InDesign CS2 is still the only way to go. For the vast majority of the design and publishing market that isn’t in a closed workflow, staying current and competitive will henceforth mean using both (again).

In terms of Quark versus InDesign, people have come to summarize the war and every individual’s opinion of both applications in the form of a single question: Would you choose QuarkXPress or InDesign to begin new projects? Yesterday, my answer was simple: I would start roughly 5% of my new projects in XPress, using InDesign for the rest. Today, it’s not so simple an answer. I will still begin most new projects in InDesign CS2, but I’ll happily reach for XPress 7 when my project can survive the limitations and when it needs color-level transparency and advanced collaboration.

Is it a revolution?
Industry buzz said QuarkXPress 7 will revolutionize publishing. Is it revolutionary?

It’s important, certainly. It’s important because it demonstrates that Quark has finally recognized that it’s in a war for market share—and its existence. XPress 7 is important because the world needed to know whether Quark could still innovate. It can.

XPress 7 is not the InDesign-killer a vocally zealous minority purported it to be. XPress and InDesign are at war, and war is never black and white. There are no competition killers in the offing—from either side. This is not a war of marketing or price points no matter how much fans of either side try to make it so. This is a war of innovation. As long as both XPress and InDesign continue to anticipate and meet the needs of creative professionals, as long each one innovates new features the other doesn’t have while striving to meet what it does, the war will rage—to the benefit of everyone who uses either application. When the inevitable end does come, it will be because one side or the other has stopped innovating.

The printing press, that was revolutionary. So was PostScript. The World Wide Web was revolutionary. QuarkXPress 7 is evolutionary. Unlocking the one file:one designer ratio is the biggest step Quark could have taken toward the future. And, while XPress 7 still has its pain points—large and small—it’s a major step forward. It won’t forever alter the way documents are published, but it does evolve the document creation process into a higher life form.

I am thoroughly impressed with, and excited by, QuarkXPress 7, and I hope the end of the war doesn’t come for a long, long time.

Quark, QuarkXPress, Quark 7, QuarkXPress 7, InDesign, CS2, Adobe, PDF, VDP, PPML, desktop publishing, dtp, how-to