Quark 6.5 bug: some black prints in front

[Al Ferrari]

Hi All,

I have done some test to figure out the exact culprit for a problem I was having with rules coming out in front of a green bar in a Qx 6.5 job when they were in fact in back. The attached picture summarizes them. It depicts exported pdfs from a very simple Qx file with just a green box and a rule *behind* it. In each case the trap settings for the PANTONE 357 color are edited as per the text label shown on the page.

I think there is a bug in Quark 6.5 that causes the black to print as if "bring to front" had been applied, IF ONLY simple black rules are involved. If there is black text also behind the green, then the problem does NOT occur. In both of the bottom pdfs, the text "Black in back" is at the bottom of the stack in the Quark doc.

This is on a mac G4, with 10.4.11.

Have you heard of this? Is it fixed in later versions?

Al

 

[claude72]

It's an old bug... that already existed in XPress 3.0... and has been fixed in XPress 7...

(According to Quark, it's not really a bug, it's a "feature" )

I think there is a bug in Quark 6.5 that causes the black to print as if "bring to front" had been applied,

No, it's not a "back" or "front" problem, it's a knock-out/overprint problem: according to the Print rules, the green rectangle should knock-out the black line, but in fact XPress makes a mistake and set it to overprint.

If there is black text also behind the green, then the problem does NOT occur.

Yes, because adding something more behind the black line (a text or a picture) changes the way that XPress set the knock-out/overprint and then XPress (suddenly) "understands" that it had to knock-out...

You can also fix the problem by setting manually (in the overprint palette) the knock-out/overprint rule between your black line and green rectangle.

 

[Al Ferrari]

Hi Claude,

I appreciate your response very much. But I think it's off the mark for two reasons:

1. Quark only traps when it separates (I think), and the output (exported) pdfs I show are composite.

2. Note that in the Qx document the green box is in front (please check the Qx file yourself), but in the problem pdfs the box is visually in back. Your KO idea does not explain this, unless you are saying the black knocks out the green that is above it and we see through the Green?

I hope I understood you correctly.

Thank you again,

Al

 

[toronar]

Hi Claude,

I appreciate your response very much. But I think it's off the mark for two reasons:

1. Quark only traps when it separates (I think), and the output (exported) pdfs I show are composite.

Overprint is not trapping. Quark always outputs overprints, in composite as well as separation output.
You are correct that Quark does not trap when you output composite, but overprints do happen

 

[Al Ferrari]

It doesn't seem like these responses are base on having downloaded and examined the files attached to my original post. What needs to be explained is why the stacking order of the objects changes in the output depending on the color trap settings as described.

Al

 

[claude72]

Hi Al

1. Quark only traps when it separates (I think),

Yes, you're right: Xpress only traps when it separates (Quark is the manufacturer, XPress is the software!!!)... but your problem is not a trapping problem, it's a knock-out problem.

2. Note that in the Qx document the green box is in front (please check the Qx file yourself), but in the problem pdfs the box is visually in back. Your KO idea does not explain this, unless you are saying the black knocks out the green that is above it and we see through the Green?

Ok, the green box is in front, and the black line is in back, so the green opaque box covers the black line, looking as if the black line is interrupted and is in two parts...
... but offset inks are not opaque, they are transparent... so, if you print the black line first and then the green box, the green ink covering the black line will not mask the black line, that remains visible...
... so to succeed to print that correctly on an offset press, the black line has to be interrupted under the green box: the green box has to knock-out the black line... OK?

... but, a known bug in Xpress makes that when a coloured object is OVER a black object, with the default knock-out/overprint settings, Xpress "forgets" to knock-out the black object and the real result is that the coloured object overprint on the black object: its exactly what happens with your green box and your black line...

This bug is known by all the pre-press operators, as we all have been tricked at least once with it, outputting films on which the black object is not knocked-out... and when printed, of course the coloured ink doesn't mask the black ink, and the black object remains visible under the coloured object.

And its also known that adding a third object under the two first objects changes the way that Xpress handle the knocks-outs and then it works correctly... its also exactly what happens with your green box and your black line when you add your text behind...


(often, this problems occured when doing "shadowed" titles with black shadow: the title is made in red (for example), and its block is duplicated, text is set in black, and the block with the black text is placed behind the block with the red text, and shifted 1 or 2 millimeters down and right...
... the bug makes that the red text didn't knock-out the black text, and we finally get a black title with a red shadow above and left, instead of the wanted red title with a black shadow down and right...
Because a third object involved in the process makes the knock-out works correctly, the first workaround that I found was to add a third object behind the black text block, generally a very little piece of black line, 2 or 3 mm length, placed so that it is hidden by the letter of the title, and it works...
... and, I learned how to set the overprint/knock-out settings to force the red title to knock-out the black shadow without the need of a third object!!!)


This bug already existed when I began working as a pre-press operator with XPress 3.0... and it was fixed by Quark in XPress 7... so, you have the bug in your XPress 6.5, and with your black line and green box, you are in the exact situation where this bug acts.



I'm sorry, but I don't know what happens with this bug when outputting a PDF... it acts when printing films or plate in separation but you make a composite PDF, OK...
... but distilling a PDF is a kind of printing on a PostScript printer, and PDF display tries to reproduce exactly what will be printed...


Do what you want with my explanation, believe it or reject it, but I'm quite sure that it's this bug.
(to confirm, you can try 2 tests:
- first, this bug acts only when the back object is black: try to use a red or blue line, it should work correctly,
- second, this bug has been fixed in Xpress 7: try to do exactly the same tests with black line and with Xpress 7: normally you should no more have this problem)

 

[Al Ferrari]

Hi Claude,

Carefully rereading your post has caused me to change my concept of the problem as well as the way of evaluating my test results. Thank you for taking the time to explain at length.

My original complaint with XPress (thanks also for the name distinction) was based on *visual* examination of the pdf results without magnification. This was very misleading due to the colors involved (green and black) and the small stroke on the rule. The correct way to evaluate the posted pdfs is by measuring the color densities with the Output Preview tool in Acrobat Pro and/or zooming in where the black rule begins to cross the green box. The unmagnified visual evaluation creates the misleading impression that the black rule is in front because it is not interrupted by the green box in the "problem" pdfs. In those cases, both the green and the black measure 100% in the areas where the rule is overlapped by the green box, and the magnified view shows two shades of black depicted by Acrobat.

Now the reason adding the "Black in back" text" behind the box and the rule changes the green box from overprint to knock out is that the underneath color for the green box then becomes indeterminate, and the green/indeterminate color default trap setting is .144, so it does not overprint. Changing that to overprint then allows every thing to show through the green in the output.

So you are correct that the stacking order is not the issue and the stacking order is not being changed. As explained above, that was an incorrect evaluation of the visual result. The bug I suspected does not exist.

As to the bug you are referring to for the case of the red text with a black shadow behind, the explanation would be more involved. The trap information pallet reports the underneath color for the red text to be white, not black, so it overprints by default. Changing the red text trap setting to KO takes care of the undesired overprint. A lot more can be said on this, but it does not bear on my original problem, and you seem to have workable solutions for this, so I will not comment further.

Thanks again,

Al

 

[oxburger]

Do you necessarily have to have Quark trapping even turned on? We always go into our Quark preferences and turn trapping off before we generate .pdfs because we trap all our files using trapping software and don't want Quarks preferences interfering with the Rip's trapping. Try turning off trapping and/or setting colors to "knockout all" before generating your pdf and see if that works....(see attached)

 

[Al Ferrari]

Thanks for the reply oxburger,

But I'll turn the question around to you:

Since we are agreed (you are included, no?) that EXpress only traps when it separates, and we are exporting composite pdfs for trapping at the rip, do you necessarily have to turn trapping off?

As for the original problem, I have already explained that it was only an incorrect evaluation of results on my part.

Al

 

[oxburger]

We've never experienced the problem you describe....yet. We only started recently exporting .pdfs out of Quark. The turning off of the trap is a holdover from the old days that I still do out of force of habit (is it necessary? who knows). We output as composite as well using device N and haven't run into any overprint problems problems. Is it because we turn off trapping? Not sure... but as the saying goes, if it ain't broke, don't fix it.


or as the guys on Red Green say: "if it's not straight, is too tight, or doesn't fit, you haven't hit it hard enough"

 

[claude72]

We've never experienced the problem you describe....yet.

Lucky man!!! This overprint bug between black and a spot color exists in XPress since at least the 3.1 release... and was fixed in the 7 release!!!...

... but perhaps that your RIP that is able to handle trapping is also able to override XPress overprint/knock-out settings and do its own (correct) overprint/knock-out?

 

[Zinn]

We have been very lucky here, our rip handles this issue for us, so we haven't experienced the problem.

 

[irreality]

Do you necessarily have to have Quark trapping even turned on? We always go into our Quark preferences and turn trapping off before we generate .pdfs because we trap all our files using trapping software and don't want Quarks preferences interfering with the Rip's trapping. Try turning off trapping and/or setting colors to "knockout all" before generating your pdf and see if that works....(see attached)

Ill second this one.... Just turn it off.....

 

[Al Ferrari]

Again, why bother if you are outputting composite from EXpress? Have you actually had that make a difference in such a case?

Al

Edit: I am not trying to argue. I really want to know if this makes any difference in composite output (including Device N).

 

[muminn]

Quark Express 5 doesn't seem to have this problem. Unless you print separations from QXD, which is famous for not knockout black colors on back.

Regards.

PS. Hope Xpress will be an history for a short time.

 

[Al Ferrari]

Hi muminn,

Thanks for the response. But if you read the rest of the thread, you'll see that EXpress 6.52 turns out not to have this problem after all. The whole thing was an incorrect evaluation of results on my part.

Al