Forum Moderators: open
My brother is totally baffled by this. He's used this workflow for over five years and is therefore pretty familiar with it, and he's never seen anything like this before. Unfortunately we're coming right up to the deadline for this job, so we really need to find the answer quick.
Anybody else seen this? If so, what's the fix?
He has Quark 7.2 and Acrobat 5.0 on Windows XP, in case that makes a difference.
Thanks for any ideas!
Type I fonts or TrueType?
If you are using TrueType in your original, the print shop may be using Type I and it may be substituting it on the fly.
Do you provide all fonts with your document, or embed the fonts in the doc when exporting? Try both ways.
If all else fails, this one takes a little more work and *used* to be the standard method for preparing files for a printer: Figure out where the tools are in Quark to prepare/export documents for printing. It should create a package of folders and fonts so the original can be opened and they can print it directly to their output device. Alternatively you can get their output driver and print a PostScript file.
Lastly, make sure it's not just trapping settings that are futzing up the mix. I Trapping is the effect of widening the intersection of one color over another so you don't get a white line where they meet in actual printing. If you have, say, dark type on a background, some programs have trouble figuring out which one should spread and which one should choke. It may be spreading the type instead of choking the background, giving the false impression the type is using bold face.
It shouldn't be trapping since this is just plain black text on a white background. Maybe there's something I don't know about trapping though.
We just tried the export procedure you mentioned and pre-press is looking it over now. I'll let you know if they find anything; in the meantime, we'll continue to appreciate any further ideas! :)
The thing that's so puzzling is that we've done this exact procedure many, many times and never had this problem before...
Is it possible that someone used the "B" feature from the styling menu?
If the text box is touching a picture box, I believe the trapping will come into play also.
I passed this on to my brother and he tried entirely removing the pictures from one of the problem areas just to test...unfortunately still no dice.
Is it possible that someone used the "B" feature from the styling menu?
First thing we checked! ;)
Keep the ideas coming though - we're really coming down to the wire, and evidently pre-press isn't finding anything yet either or we'd have heard from them by now.
I have seen issues where certain fonts just will not convert properly in pdf. It tends to be those that have very thin lines and are not your typical fonts.
We're not sure, but we think this may have been a bug triggered by some text formatting before the text was brought into Quark. We certainly didn't set the colors that way on purpose; we've known better than that for years.
So anyway, this problem is finally solved. Thanks for helping us troubleshoot!
a white background
A background or paper, i.e., nothing at all behind it? Registration black should STILL overprint, as I recall.
Our experience has been (and I'm sure you've seen this too) that a good printer can print registration black okay, but the type still "spreads" a bit to take on a heavier appearance. So we always use 100% black instead. I don't know why we didn't think to check the color, except that there was no logical reason it should have been different...
