Anyone who favors Xpress over Indy has their head in the sand and refuses to pull it out long enough to test each program fairly. I apologize in advance if I'm insulting anyone, that is not my intent, rather that we not sugar-coat the facts. Straight talk is far more valuable. I have no "favorite" software. I watch the facts and live with them daily. Also, I'm speaking from two decades of experience with this stuff. I've seen the history pass before my eyes.
An earlier post in this thread brought up the real issue: PostScript versus PDF, which is the format the Adobe PDF Print Engine (APPE) consumes. Postscript, and it's consumer, CPSI, is yesterday's technology. Postscript cannot, and will never process transparency. Any application (including Adobe's), when writing PostScript for a page using transparency, achieves the desired effects by using tricks that help PS get there.
On the other hand, PDF since 1.4 does understand transparency. While Indy can do both PS and PDF, when it does PDF, PS is left out of the equation. And when that PDF is left unflattened and given to an APPE renderer, PS is never involved. This is the new world of prepress -- flattening is delayed until rendering, as it was meant to be all along (we have finally arrived, and ended the nightmare launched by AI9, a cart before the horse nightmare).
The problem with XPress: it's underlying technology *appears* to remain PostScript. Which, no doubt, it was king of in its day. The entire reason XPress was better back in the day: tight integration with Adobe and the PS libraries gave Quark the upper hand on everyone else. XPress made better PS due to a close relationship with its inventor: Adobe.
But then something happened, which was the beginning of the end. Time for a history refresher. Some years back, Quark (the company) made a hostile takeover attempt aimed at Adobe. A ridiculous idea IMO, but whatever. It failed, not too big a surprise, but the real impact of this business strategy is that it soured relations between the two DTP giants. A funny thing happened after that -- Quark was denied licensing to the (then) emerging PDF libraries. And so Quark had to obtain clone PDF libraries (I believe, that XPress currently uses the JAWS PDF interpreter. Or at least it had last I saw. Please, chim in, anyone with other facts).
So the thing is, in this day and age of PDF, Quark is the estranged family member. It's too bad, the program was, and still is a great interface, no question. But there's so much it can't do, because it's been crippled by its now rival, which was a former friend. And what XPress tries to do, in some cases, it fails at so miserably it's almost embarrassing.
Today is a good example -- I have an XPress 8 job with Photoshop EPS placed. Not a problem for me, but I sure feel sorry for the designer who used circa 1995 techniques to composite all the overlaying imagery in Photoshop. They could have assembled all that in the layout if using Indy, in a fraction of the time. Anyway, that's not the real prepress issue here. This time around, the job did not match the color of the last time, not even close. I was elected to investigate.
My discovery: if a Photoshop EPS has a profile attached, XPress re-separates the image, even though it's already CMYK. I'm not shocked by that. Some workflows have the same tendancy. The part that shocks me is how terrible of a job it does. The color management module in Quark 8 is horrible. Even when all the correct profiles are aligned (we shoot for GRACoL G7), the program produces garbage. The color was mangled.
The result of my investigation is that the earlier job did NOT have any profiles saved in the Photoshop EPS files, so XPress left the images alone and they looked great. This time, with profiles embedded in the EPS files, XPress did it's ugly thing.
Does Indy do this? I don't even know. But I'll say this: I have all profiles set (as I tried to replicate in XPress, to no avail), and when I process jobs using Indy with placed Photoshop elements, profile set or not, there isn't any mangling of color. If Indy is re-separating, it's doing a damn good job of it, to the point that no one notices.
To close on XPress, the sorest spot for me (and should be for any designer using it) is that XPress can't import transparency correctly (from a PDF with native transparency, or layered PSD). Maybe version 8 can place a PSD, but that doesn't mean it comes out right at our end. It does NOT. Indy does it without a second thought, spot colors and everything (at last).
Now, to flip the coin: this doesn't mean, by any means, that I'm a fan of CS4. Yikes! ENOUGH of object-oriented programing. (my definition: choice of lazy programmers, a language saves them time). The performance of AI-CS4 is a DOG compared to CS3. It's killing my productivity. Optimize (write in plain C maybe?) most of that code so it moves, moves, moves, for the USER, not the programmer. In that respect, yes, in days past and today, at least the programmers at Quark always were pioneers of tight code.
William Campbell
Revere Graphics Portland Oregon USA
[email protected]