QuarkXPress 7: the Good, the Bad, and the Ugly

In pre­vi­ous edi­tions of XPress, spac­ing out or align­ing mul­ti­ple objects was, like most oth­er actions, accom­plished through a dia­log box. Items could be dis­trib­uted or lined up hor­i­zon­tal­ly rel­a­tive to their areas, cen­ters, or left or right edges, or ver­ti­cal­ly rel­a­tive to their areas, cen­ters, or top or bot­tom edges. The exact space between them could be spec­i­fied as well, of course. How the aligned or dis­trib­uted objects relat­ed to the page was not some­thing with which XPress con­cerned itself. XPress 7 takes that part more seriously.

Rather than the famil­iar Space/Align Items dia­log, XPress 7’s Measurements palette has–you guessed it–a Space/Align mode. Instead of the multi-step process of select­ing radio but­tons and menu items before objects move, the new method is much faster and famil­iar: just click an align­ment or dis­tri­b­u­tion but­ton. All the usu­al options are there, as well as a new Page Relative Mode that lines up or spaces out the select­ed objects rel­a­tive to the page’s edges and/or ver­ti­cal and hor­i­zon­tal cen­ters. Want to put an object dead cen­ter on the paper? Forget about doing the math–just click a but­ton the Measurements palette.

With this new func­tion­al­i­ty comes one sac­ri­fice: You can no longer spec­i­fy the amount of space between dis­trib­uted objects unless Page Relative Mode is enabled. Thus, it’s not pos­si­ble to dis­trib­ute a selec­tion of objects across an entire spread in a sin­gle step. All things con­sid­ered, it’s a more than equi­table trade-off.

XDraw
One of the biggest and fur­thest reach­ing changes to XPress 7 is the new XDraw screen ren­der­ing lay­er, which actu­al­ly runs off the graph­ics engine of the host oper­at­ing system–GDI+ on Windows and Quartz on Mac. XDraw final­ly brings to XPress an accept­able lev­el of con­fi­dence in the rela­tion­ship between onscreen work and out­put. If you’re new to XPress, it may come as a shock that now is the first time in the 20 year his­to­ry of QuarkXPress that it has had WYSIWYG.

In past ver­sions, any seri­ous for-print work required numer­ous print­ed proofs or at least print­ing to PDF where Acrobat would sub­sti­tute for what XPress should have had all along. There sim­ply was no reli­able way to work on the details of a design–especially those involv­ing images, small type, or tight clip­ping paths–without print­ing, and work­ing from, a proof.

Now, XPress’s dis­play is not only as accu­rate as oth­er appli­ca­tions, it’s gor­geous. Moving around even shadow- and transparency-laden lay­outs is smooth and stutter-free, the doc­u­ment win­dow updat­ing faster than I could have dreamed.

Drop Shadows
Been there, done that, right? Heck, InDesign has had drop shad­ows since CS. XPress is just play­ing catch up; noth­ing new to see here, right?

Wrong.

Photoshop’s drop shad­ow con­trol is the gold stan­dard by which all oth­er appli­ca­tion­s’ imple­men­ta­tions of this very pop­u­lar fea­ture are weighed. XPress 7’s is not up to that standard–and shouldn’t be, it’s not an image edit­ing appli­ca­tion. It isn’t a dupli­cate of InDesign’s method for cre­at­ing drop shad­ows either. While many new XPress fea­tures can’t be com­pared head-to-head with InDesign’s, drop shad­ow cre­ation and con­trol is eas­i­ly com­pared. Both appli­ca­tions bring their own style to the fea­ture, and both come clos­er to Photoshop’s method in their own ways.

In InDesign CS2, drop shad­ows inter­act with objects behind them using blend­ing modes such as Multiply, Color Dodge, Color Burn, Luminosity, and twelve oth­ers. Shadow con­trols include set­ting opac­i­ty inde­pen­dent of the object cast­ing the shad­ow, sep­a­rate X and Y off­sets, blur, spread, and noise, which, when used judi­cious­ly, can enhance the real­ism of drop shad­ows. The col­or of the shad­ow may be cho­sen from swatch­es pre-created on the Swatches palette, or mixed with RGB, CMYK, and Lab slid­ers. Once the Preview box is checked, all changes effect­ed in InDesign’s Drop Shadow dia­log pro­vide instant feed­back 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 pre­view. There are only two blend­ing modes–normal and multiply–which lim­its the effects pos­si­ble with this fea­ture to drop shad­ows or sim­ple out­er glows. Use the mul­ti­ply mode when the drop shad­ow is dark­er than the objects behind it. This will keep the dark­er shade, whether that belongs to the shad­ow or the col­or beneath, while lighter shades are dis­card­ed. In nor­mal blend­ing mode (mul­ti­ply off), the col­or of the shad­ow is direct­ly blend­ed with the col­ors of objects beneath–the pre­ferred method when your shad­ow is any­thing but black.

In addi­tion to the blend­ing modes, there is an opac­i­ty slid­er for con­trol­ling the shad­ow opac­i­ty, and an option to force the shad­ow to inher­it the opac­i­ty of it’s host object–in oth­er words, if the object is 50% trans­par­ent, the shad­ow will be too, even if the shad­ow is specif­i­cal­ly set to be 100% trans­par­ent. This is a cool fea­ture because it enables shad­ow opac­i­ty rel­e­vant to its host object–as one is made more or less sol­id, the oth­er updates to match. Another nifty option Quark saw fit to include was the abil­i­ty to knock the shape of the object out of the shad­ow. With an opaque object, this tog­gle has no effect. But, if the object or any of its col­ors are par­tial­ly or ful­ly trans­par­ent, you have the option of choos­ing whether the drop shad­ow shows through. Think of a text box that has no fill, but it’s drop shad­ow still doesn’t show inside the area of the box itself.

Shadow posi­tion­ing con­trols are where XPress 7 and InDesign real­ly diverge, each hav­ing its strengths and weak­ness­es. In XPress, a skew field enables the cre­ation of a rudi­men­ta­ry cast shad­ow, some­thing InDesign can’t do. In fact, not even Photoshop can do it bet­ter than XPress with­out a third-party plug-in. A shad­ow blur con­trol in XPress doesn’t stand up against InDesign’s spread, noise, and blur options. Neither does the sin­gle dis­tance mea­sure­ment, which con­trols how far a shad­ow falls from an object’s top left cor­ner (the “origin”). Between the angle and dis­tance con­trols, you have all the same free­dom as InDesign’s inde­pen­dent X and Y shad­ow coor­di­nates, but it takes more prac­tice to get the get same result in XPress. However, the pres­ence of one tiny check­box in XPress makes the effort more than worth it: Synchronized Angle.

If you’ve used the drop shad­ow lay­er style in Photoshop, you should imme­di­ate­ly under­stand the pur­pose and con­ve­nience of this fea­ture. Checking Synchronized Angle on sev­er­al objects keeps the angles of those object­s’ shad­ows iden­ti­cal, cre­at­ing the illu­sion of a sin­gle light source affect­ing them all. Changing the shad­ow angle on any such object auto­mat­i­cal­ly changes them all–a huge time saver. Although Photoshop has this option (called Global Angle there), InDesign doesn’t; InDesign’s drop shad­ows are not linked in any way, and the Drop Shadow dia­log box resets to default options every time it’s used on a new object.

Runaround can also be set to account for a drop shad­ow. By default, runaround only applies to an object, ignor­ing a drop shad­ow, even if that means text over­lap­ping the shad­ow. Often times, that’s desired behav­ior, but when it isn’t, XPress 7 pro­vides the option of forc­ing text to runaround the shad­ow as well as it’s host object–this is some­thing InDesign can also do, but only by man­u­al­ly edit­ing the shape of the text wrap (A.K.A. runaround) bound­ing box.

One major draw­back I found with XPress 7’s drop shad­ows is that, on screen, shad­ows are not nec­es­sar­i­ly accu­rate rep­re­sen­ta­tions of the print­ed out­put. Toggling the Multiply Drop Shadow option, for exam­ple, which deter­mines whether the shadow’s blend­ing mode is set to mul­ti­ply or nor­mal, shows no dif­fer­ence between them on screen. Printing the two modes, how­ev­er, reveals sig­nif­i­cant dif­fer­ences in the way back­ground object col­ors blend through the shad­ow. It could eas­i­ly make the dif­fer­ence between a believ­able com­po­si­tion, and a col­lec­tion of objects. This could be a cost­ly gotcha on press.

Which one does drop shad­ows better–XPress or InDesign? That depends entire­ly on the shad­ow you want. In one case, XPress is bet­ter, InDesign in anoth­er. Keep Photoshop handy for those times when you need more than either can offer.

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

Succeeding the lega­cy of both PostScript Type 1 and TrueType fonts is OpenType, a Unicode (double-byte) intel­li­gent font for­mat capa­ble of hold­ing all the world’s cur­rent­ly active–and even yet to be created–written languages–and much more–in a sin­gle .OTF or .TTF font file. PostScript and TrueType fonts only have space for 256 char­ac­ters per font, which is extreme­ly lim­it­ing and led to incon­sis­tent assign­ment of slots–one font may use slot X to hold a trade­mark sym­bol, while anoth­er font may stick a vir­gule in slot X and insert the trade­mark sym­bol some­where else. With OpenType’s gen­er­ous num­ber of slots, every glyph has its own pre­de­fined place that is, and must be, con­sis­tent across all OpenType fonts; if a type design­er intends to draw a trade­mark sym­bol, it may only be placed into slot X and nowhere else. Similarly, if the type design­er decides not to draw a trade­mark sym­bol, that slot must be left empty.

Even after fill­ing up the OpenType slots with all Western lan­guage glyphs and their var­i­ous accents, lig­a­tures, and sym­bols, then doing the same for Chinese, Japanese, Korean, Arabic, and oth­er lan­guages, there are still many, many slots avail­able. Consequently, those slots are tasked with hold­ing oth­er sorts of glyphs, like alter­nate ver­sions of let­ters and sym­bols. It’s pos­si­ble, for exam­ple, to find a sin­gle font file incor­po­rat­ing not only one com­plete set of upper- and lower-case let­ters, but also a gen­uine small caps set–drawn at small caps size, with stroke weights match­ing caps and low­er­case glyphs–as well as titling alter­nates, swash­es, sev­er­al dif­fer­ent styles of numer­als (e.g. sep­a­rate­ly drawn fixed-width, vari­able width, numer­a­tor, denom­i­na­tor, supe­ri­or, and oth­er styles), and many, many oth­er glyphs. Where Type 1/Type 3 or TrueType fonts required sev­er­al font files to pro­vide all of the above–with the attend­ing dif­fi­cul­ties of type­set­ting lines of copy in mul­ti­ple fonts–a sin­gle .OTF (or OpenType ver­sion .TTF) file can now han­dle it all.

Now that you under­stand some of the val­ue of OpenTypes to a pro­fes­sion­al pub­lish­ing workflow–and it’s impor­tant to rec­og­nize that the above is a sig­nif­i­cant­ly abbre­vi­at­ed description–you should know that XPress can final­ly use them in ver­sion 7. OpenTypes can be used with ear­li­er ver­sions of XPress, as long as the oper­at­ing sys­tem under­stands them, but they’re treat­ed like TrueTypes in those ear­li­er ver­sions; it isn’t until XPress 7 that you have access to the fea­tures and ben­e­fits of OpenType fonts.

OpenType fonts are ful­ly cross-platform–gone is the need to fear char­ac­ter sub­sti­tu­tion, text reflow, and oth­er com­mon issues of col­lab­o­rat­ing between Windows and Mac. The same OpenType font works–and works exact­ly the same–on Mac, Windows, and Unix. During my test­ing of XPress 7, I trans­ferred XPress projects and their fonts between Windows XP and OS X sev­er­al times. At no time did a sin­gle let­ter of any text box reflow, nor did any sym­bol or accent­ed char­ac­ter sud­den­ly turn into some­thing else.

In OpenType sup­port, XPress is most cer­tain­ly play­ing catch-up. To put it in con­text: even Photoshop, an image edi­tor, laps XPress 6.5 in type­set­ting pow­er. Making good use of OpenType required a rewrite of XPress’s text engine, which took time. Now that it’s done, XPress is final­ly back in the game of pro­fes­sion­al grade type­set­ting. It does not yet sup­port every fea­ture of OpenType–and not as many as its competitors–but in a sin­gle bound it cat­a­pult­ed from the Stone Age into the mod­ern world.

So what’s still miss­ing? Certain con­tex­tu­al OpenType fea­tures that change glyphs on the fly (if acti­vat­ed), such as chang­ing the sec­ond instance of the let­ter e in a word to a dif­fer­ent ver­sion of the e for vari­ety, aren’t ful­ly sup­port­ed. They work on sim­ple occa­sions, but become less reli­able as the com­plex­i­ty of con­tex­tu­al replace­ment increas­es. Stylistic sets are also missing.

Fractions are han­dled in an odd way, too. OpenTypes have spaces for the most com­mon fractions–1/2, 1/4, 1/3, and so on–as sin­gle glyphs, much like Type 1 and TrueType fonts. They also have slots for all 0–9 numer­als drawn as numer­a­tors and again as denom­i­na­tors and the instruc­tion­al cod­ing nec­es­sary to build frac­tions from those glyphs. Unlike the pre-drawn frac­tion glyphs, built frac­tions con­sist of at least three glyphs insert­ed and kerned to cre­ate the appear­ance of a sin­gle frac­tion­al glyph. In English, that means the frac­tion 5/9 would be cre­at­ed from the 5 numer­a­tor glyph, a solidus (slash), and the 9 denom­i­na­tor glyph. In some cas­es, XPress 7 bypassed the pre-drawn com­mon frac­tions like 1/2 to build them using the three-glyph method. Whether this is an issue with the beta or intend­ed that way is not known. It’s a minor point, regardless.

Because of the way XPress reads and inter­prets OpenType fonts, they may appear in the type­face menu with slight­ly dif­fer­ent names than in oth­er appli­ca­tions. This is a choice XPress is mak­ing about which inter­nal font name and ID fields to read and use. There are sev­er­al fields, with dif­fer­ent types and lengths of font titles and IDs, and XPress choos­es them dif­fer­ent­ly than some oth­er appli­ca­tions. It’s worth men­tion­ing here because it can be dis­con­cert­ing or even frus­trat­ing 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 cus­tom­ary quirks and is miss­ing a few use­ful OpenType fea­tures, it does sup­port the major­i­ty of OpenType–certainly the most com­mon­ly used fea­tures. For every one thing XPress 7 does wrong or odd­ly in this area, it does ten oth­er things absolute­ly right.

Via the OpenType menu on the Measurements palette (in Character Attributes mode), you have access to ten dif­fer­ent major OpenType fea­tures, four styles of gen­er­al numer­als, and four styles of spe­cial numer­als (superscript/superior, subscript/inferior, numer­a­tor, and denom­i­na­tor). Depending on the font, some, none, or all of these fea­tures may be avail­able. Those wrapped in brack­ets are unavail­able because they were not includ­ed in the font–not all OpenType fonts include all the fea­tures. Script fonts, for exam­ple, rarely have a need for more than a sin­gle type of figure.

Among the poten­tial­ly avail­able OpenType fea­tures are: stan­dard lig­a­tures (fi, ff, fl, etc.); dis­cre­tionary lig­a­tures (ct, st, ch, etc.); scale-appropriate ordi­nals (1st, 2nd, 10th, etc.); titling alter­nates, alter­nate ver­sions of glyphs for use at larg­er sizes; all small caps to con­vert a mixed case arrange­ment of let­ters to gen­uine small caps; small caps, which con­verts all low­er­case let­ters to gen­uine small caps; frac­tions to con­vert any typed frac­tion (e.g. 1/12) into a prop­er set of numer­a­tor, solidus, and denom­i­na­tor, and; con­tex­tu­al alter­nates, which, sim­i­lar to lig­a­tures, search­es for arrange­ments of glyphs that would be more aes­thet­ic or read­able using alter­nate ver­sions of some of its con­stituent glyphs (e.g. replac­ing the sec­ond g in jig­gling with a smaller-tailed ver­sion to increase readability).

OpenType options can be applied any­where you can apply oth­er text attributes–selectively to high­light­ed text, or as part of char­ac­ter style sheets, which, of course, can be incor­po­rat­ed into para­graph style sheets. I rec­om­mend you set your default Normal char­ac­ter style sheet to an OpenType, and turn on stan­dard lig­a­tures so you won’t have to man­u­al­ly set this fun­da­men­tal option. Depending upon what kind of type you nor­mal­ly set, you may want to add oth­er OpenType fea­tures to your default Normal char­ac­ter style sheet as well.

Setting aside every oth­er new fea­ture of XPress 7, true sup­port for OpenType fonts and most of their capa­bil­i­ties is the sin­gle biggest step Quark could have tak­en to bring XPress into the mod­ern world of type­set­ting. It has a few issues (not­ed below under the “The Ugly” sec­tion), but, in the case of OpenType, the scales are over­whelm­ing­ly heavy on the what-they-got-right side.

Glyphs Palette
With OpenType sup­port comes a new Glyphs palette for get­ting at each font’s rough­ly 65 thou­sand poten­tial glyphs. It’s very sim­i­lar to InDesign’s, but that isn’t a knock against XPress–it’s just an effec­tive solu­tion. This–in XPress 7–is what a Glyphs palette should be. I won’t say it’s per­fect, but it’s close.