Itâ€™s the most powerful, most feature-packed version of QuarkXPress ever built, they said. It stimulates creativity and inspires organic work, they claim. They said it will revolutionize publishing. Quark VS InDesign.com goes deeper into QuarkXPress 7 than anyone before to see if they were right.
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.
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.
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.
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 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.
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.
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.
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.