Misbehaving DCS files

in article , Odysseus at
wrote on 9/17/04 12:50 PM:

Photoshop (CS) v8.0 under Mac OS v10.3.5 on a G4/733 with 1GB RAM.
I recently received for output four CMYK flyers done entirely in Photoshop (Windows, not sure which version but quite recent), with lots of layers of type, vector effects, &c. Three of the four were set up at 600 ppi, and the other at 300. After editing the files (adding bleeds, inserting adjustment layers to turn 100/100/100/100 objects into a normal rich black, &c.) I saved them in Photoshop format then, as is my habit, made copies in DCS1 format for output, first downsampling the 600-ppi files to 300. Hoping to get the best possible definition from the type &c., I checked the box to include vectors.

Each separation of the originally-300-ppi file showed a size of about 13 MB. A little high, I thought (the ‘nominal’ size of the original being about 34 MB), but no big deal. OTOH the others weighed in at 45-50 MB each, despite having been downsampled. Must be the vectors, I thought … Well, an imposed file of all four wouldn’t go through our ECRM (Harlequin) RIP, generating a PostScript error. Deciding there must have been something whacky in the vector data — I haven’t any experience outputting Photoshop vectors — I went back to my layered originals, flattened them (downsampling the three oversized ones to 300 ppi again), and saved as DCS1 (of course the vector-inclusion option was now greyed out). To my great surprise, the file sizes were the same as before! And they still failed to RIP.

Pretty well desperate by now, I opened the DCS files in my old Photoshop
5.5 under Mac OS 9.2 and resaved them in the same format; now they all
showed the expected 8+ MB per plate, and my four-on imposition went through the RIP just fine.

Any ideas as to what might have been going on here? Are there known bugs in saving in DCS format from Photoshop 8 / OS X? If so, is it just DCS1, or DCS2 as well? The latter would be a real problem; while I use DCS1 essentially for convenience, speeding up parts of our workflow, the only way I know to get arbitrary spot colour plates into another application is _via_ DCS2, making it essential for some jobs. Or might it be that for some reason (appearances to the contrary) the flattening (or downsampling) didn’t actually ‘take’?

—
What application are you placing the files into for output? Are you sending eps or pdf to the RIP?
–
The way to preserve vector data in a Photoshop file
is to save the file as a Photoshop pdf (pdp) file.
–
If you have to work with DCS files to use spot colors … place the DCS into InDesign and export the graphic as a PDF. You will then have a compace spot color PDF
and will not have to screw around with DCS files.
–
Did you comp files contain smaller placed or imported Photoshop pieces? Did any of those have compression or alpha channels
(especially those 2 thing together)?
–
You maybe should look into feeding your RIP pdf files.
You could be sending the RIP 10 meg files
instead of 200 meg files.

MSD

Odysseus …

Photoshop (CS) v8.0 under Mac OS v10.3.5 on a G4/733 with 1GB RAM.
I recently received for output four CMYK flyers done entirely in Photoshop (Windows, not sure which version but quite recent), with lots of layers of type, vector effects, &c. Three of the four were set up at 600 ppi, and the other at 300.

So you say you do color correction and adjust black generation, etc. Are you authorized to do that by the client? If you are not, why don’t you receive the files in PDF 5 (or higher) format?

(Harlequin) RIP, generating a PostScript error. Deciding there must have been something whacky in the vector data —

How did you decide that? What was the PostScript error?

Any ideas as to what might have been going on here?

Have you actually made sure that no font is missing?

Mohamed Al-Dabbagh
Senior Graphic Designer

In article ,
(Mohamed Al-Dabbagh) wrote:

Odysseus wrote in message
news:…

Photoshop (CS) v8.0 under Mac OS v10.3.5 on a G4/733 with 1GB RAM.
I recently received for output four CMYK flyers done entirely in Photoshop (Windows, not sure which version but quite recent), with lots of layers of type, vector effects, &c. Three of the four were set up at 600 ppi, and the other at 300.

So you say you do color correction and adjust black generation, etc. Are you authorized to do that by the client? If you are not, why don’t you receive the files in PDF 5 (or higher) format?

The files were supplied in CMYK. I only changed the objects that were going to be solid in all four colours, because 400% coverage can create a major problem on press. As for the file format, I have to deal with what I’m given; since I work in a trade shop, the creator of the file is often at second or third hand to the immediate client. And I don’t have any tools for fixing problems like an unprintable colour or complete lack of bleed in PDFs — Acrobat 6 can tell me about some of them, but is no help for changing most of them. Sure, it would make my job easy just to say, "Your file’s no good," but that’s not what I’m paid for.

(Harlequin) RIP, generating a PostScript error. Deciding there must have been something whacky in the vector data —

How did you decide that? What was the PostScript error?

"Guessing" might have been a better way to put it than "deciding" — the inclusion of vectors was the only aspect of the job that was unusual for me. The PS error was a limitcheck, the quoted offending command being a long string of ‘gibberish’, non-alphabetic characters.

Any ideas as to what might have been going on here?

Have you actually made sure that no font is missing?

There were no little alert triangles on any of the type layers. Is there some other way to tell? Doesn’t Photoshop just use its rasterized version of a type layer set up with an unavailable font, until you try to edit it? Anyway, I don’t understand how a missing font would cause a *flattened* file that should be 34MB to balloon to 200 MB.

—
Odysseus

"Guessing" might have been a better way to put it than "deciding" — the inclusion of vectors was the only aspect of the job that was unusual for me. The PS error was a limitcheck, the quoted offending command being a long string of ‘gibberish’, non-alphabetic characters.

Aha…it wouldn’t happen to be a Level 1 RIP, would it? (Limitcheck errors are rare in Level 2 RIPs.)

A Limitcheck error means an internal RIP limitation has been reached–for example, a path contains too many points for the RIP to be able to render.

—
Art, literature, shareware, polyamory, kink, and more:
http://www.xeromag.com/franklin.html

In article <BD71A144.1C4AC%>,
WharfRat wrote:

What application are you placing the files into for output?

QuarkXPress 4.

Are you sending eps or pdf to the RIP?

Neither: straight PostScript, via Farrukh Imposition Publisher.

The way to preserve vector data in a Photoshop file
is to save the file as a Photoshop pdf (pdp) file.

Why does it show an option to do include vectors in the DCS export dialog, then? At any rate I need CMYK separations, and I can’t see any option in Photoshop’s Save As PDF dialog that will give me anything other than a composite file.

If you have to work with DCS files to use spot colors …

Not this time: it was DCS1, which I use instead of plain EPSF to speed up proofing, relieve QX of having to do the separation itself, and reduce the size of the ‘fat’ PostScript by a factor of four.

place the DCS into InDesign and export the graphic as a PDF. You will then have a compace spot color PDF
and will not have to screw around with DCS files.

But QX sucks at separating PDFs. In this case I suppose I could have done the printing from ID — maybe I’ll give it a try with the bloated files that caused an error when printed from QX — but at any rate PDFs would be pretty much a ‘dead end’ for printing anything but colour proofs. Another problem with Photoshop PDFs, from my point of view, is that I don’t know of any way to include trim-size information in a page with bleeds.

Did you comp files contain smaller placed or imported Photoshop pieces? Did any of those have compression or alpha channels
(especially those 2 thing together)?

I don’t know what you mean by "comp files"; the DCS master file would only be used for running a b/w laser proof. I never use JPEG encoding in my DCS files, and the format doesn’t support alpha channels in the first place. But the original Photoshop file contained many layers, some of them with masks, although in my final effort with v8, before I switched to v5.5, the file I saved as DCS had first been flattened and contained no extra layers or channels at all.

You maybe should look into feeding your RIP pdf files.
You could be sending the RIP 10 meg files
instead of 200 meg files.

I don’t trust the RIP to do its own separations; there’s no way to evaluate the results without outputting film, or trying to guess the percentages from the "Roam" preview. Since I don’t have Quite A Box of Tricks, CrackerJack, or anything like that, I have no means of turning RGB black into 100%K or fixing other such problems inherent to composite colour outside of a colour-managed workflow. OTOH once I’ve created seps I know nothing will mess with the CMYK values on the way.

Thanks to you and Mohamed for your suggestions about a PDF workflow &c. — believe me, I’ve put in many requests to my employer to get some PDF-editing software, colour-management tools, in-RIP trapping, &c. in here — but what I most want to understand is why Photoshop 8 would turn four 34-MB flattened files into over 600 MB of DCS files that wouldn’t RIP, and why resaving the files from Photoshop 5.5 apparently solved the problem.

—
Odysseus

Thanks to you and Mohamed for your suggestions about a PDF workflow &c. — believe me, I’ve put in many requests to my employer to get some PDF-editing software, colour-management tools, in-RIP trapping, &c. in here — but what I most want to understand is why Photoshop 8 would turn four 34-MB flattened files into over 600 MB of DCS files that wouldn’t RIP, and why resaving the files from Photoshop 5.5 apparently solved the problem.

—
Sorry not to be more help…
Not much experience in what you are doing.
I would never consider using Photoshop to output a file to a RIP.

MSD

In article ,
(Tacit) wrote:

"Guessing" might have been a better way to put it than "deciding" — the inclusion of vectors was the only aspect of the job that was unusual for me. The PS error was a limitcheck, the quoted offending command being a long string of ‘gibberish’, non-alphabetic characters.

Aha…it wouldn’t happen to be a Level 1 RIP, would it? (Limitcheck errors are rare in Level 2 RIPs.)

No, I believe it’s Level 3, albeit non-Adobe: it identifies itself as "Harlequin RIP Eclipse Release SP0b".

A Limitcheck error means an internal RIP limitation has been reached–for example, a path contains too many points for the RIP to be able to render.

In this case I rather suspect the ‘gibberish’ represents what was being interpreted as an operator name, but being some other kind of data instead, exceeded the allowable length for a dictionary key. I’d expect a limitcheck caused by too many points, or by insufficient flatness, to give a path-construction or painting operator as the offending command in the error message.

—
Odysseus