Thread View: adobe.postscript.programming
8 messages
8 total messages
Started by Trajan
Thu, 18 Sep 2003 17:34
Adobe CPSI
Author: Trajan
Date: Thu, 18 Sep 2003 17:34
Date: Thu, 18 Sep 2003 17:34
5 lines
988 bytes
988 bytes
I've searched the website for more info on Adobe's CPSI, with little results. What I need is a better understanding of CPSI, especially in regard to its relationship to other PostScript drivers and interpreters. Is there a white paper or other documentation that can be accessed fairly easily?
Re: Adobe CPSI
Author: Dov Isaacs
Date: Thu, 18 Sep 2003 18:14
Date: Thu, 18 Sep 2003 18:14
5 lines
1038 bytes
1038 bytes
Adobe CPSI is an OEM product only! It is a version of Adobe's PostScript interpreter designed to run on "standard platforms" as opposed to embedded controllers. Specifically, what information are you interested in? - Dov
Re: Adobe CPSI
Author: Trajan
Date: Fri, 19 Sep 2003 17:10
Date: Fri, 19 Sep 2003 17:10
25 lines
4178 bytes
4178 bytes
Dov, Any info is better than none at all, which is what I currently have. I've read plenty of articles and books on prepress, imagesetters, Postscript, RIPs, etc., and hardly a word about CPSI enters the discussion anywhere. One would think that such an important aspect of what we do would merit more attention and explanation. I'm using Heidelberg's Signastation imposition software, imposing 4-up signatures from PDF files. It uses an Adobe CPSI 3.015 to parse these documents. it's output on Heidelberg's MetaDimension RIP going to an imagesetter. I'm responsible for everything except the actual file creation. What I'd like to know, in layman's terms, are the differences between the Adobe CPSI and generic Postscript drivers that, as I understand it, only interpret Postscript but don't actually rasterize it. I realize that the CPSI has an exponentially higher degree of complexity than, say, a Laserwriter driver going from OSX to a color laser printer. What I'm confused about is how "generic" Postscript is interpreted by such a device and how this compares to a non-generic CPSI. Is it safe to assume that postscript code for an imagesetter must, by design, have a higher degree of complexity than code for a PS 3 laserprinter? Therefore the CPSI's parser and the RIP perform many tasks with the code that the laserwriter's driver just ignores? I guess that I've always assumed that color PS 3 laser writers had to have a software RIP built in to rasterize the data. I'm now discovering that isn't the case; that a software RIP isn't necessary to interpret "generic" Postscript. I thought that a RIP was required for any device that interpreted Postscript. Exactly how does the interpretation of "generic" Postscript differ from a CPSI's interpretation? I work closely with a designer who uses inDesign 2.02 and loves the Export to PDF option. Everybody loves this option in ID except the people who have to convert them with a CPSI. Sometimes they work fine, other times they fail. When I tell her it fails, I get, "But it printed fine on the Postscript Level 3 laser printer -- so it must be a problem on your end (with the CPSI)." This can be very aggravating, because I don't know how to explain the difference between the two devices in a convincing, logical way. We have a PDF workflow. I'm well aware that you're supposed to create a PS file first, then distill from that instead of using ID's "Export to PDF" option. But what do you tell a designer that logically explains why an Adobe CPSI cannot interpret a PDF created by Adobe's flagship products ID and Acrobat? I don't think it's audacious to assume there should be total compatibility between all three -- unless Heidelberg wrote something into their CPSI that, indeed, is upsetting the applecart (or Adobecart). Invariably, problematic files print just fine on a "generic Postscript" laserwriter PS 3 printer. Designers are using these as proofing devices. So it's frustrating for both of us to parse the same file with an Adobe CPSI and encounter Postscript errors. No such errors were returned on the laserwriter even when she has "Postscript" (not print-as-image) and "Report PS errors" boxes checked in the Acrobat printer window. Sorry to be so longwinded. I'm just trying to get a clearer understanding (if that's possible!) of the tools we have to work with every day.
Re: Adobe CPSI
Author: Trajan
Date: Fri, 19 Sep 2003 17:14
Date: Fri, 19 Sep 2003 17:14
3 lines
946 bytes
946 bytes
PS to that last message: I need to have a logical explanation to explain to people why creating a PS file and distilling the PDF from that creates a more reliable PDF than any other method, including ID's "Export to PDF" option.
Re: Adobe CPSI
Author: Dov Isaacs
Date: Fri, 19 Sep 2003 17:59
Date: Fri, 19 Sep 2003 17:59
13 lines
3072 bytes
3072 bytes
OK, that's quite a mouthful, but let's start. (1) To take your "PS" first ... "creating a PostScript file and distilling" does NOT make a more reliable PDF than any other method. This is especially true with regards to InDesign's "Export PDF" function which produces highly reliable PDF. InDesign's exported PDF is fully compliant with the PDF 1.3 or 1.4 specification, depending upon the version of PDF you have specified for export! (2) You appear to be confusing a PostScript driver with a PostScript interpreter. A PostScript driver CREATES PostScript for subsequent interpretation by a PostScript interpreter. CPSI is one of a number of versions of PostScript interpreters licensed by Adobe to its OEMs including Heidelberg. The OEM "configures" CPSI to match the device characteristics of their hardware imagesetter, digital press, wide-format printer, etc. (3) CPSI is not a PDF interpreter; it is a PostScript interpreter. OEM products based upon CPSI that claim to interpret PDF actually first generate PostScript from the PDF using either a "PDFtoPS" component from Adobe or something similar of their own based upon a PDF Library. Thus, CPSI would not directly be the cause of any problem in interpretation of PDF exported by InDesign 2. If you are getting PostScript errors from a CPSI-based RIP from InDesign 2-exported PDF, it is because there is a problem in the creation of PostScript from PDF, not in CPSI itself. (4) Our OEMs' products that provide PDF support must have the latest upgrades and updates to support the versions of PDF that you are exporting from InDesign or Illustrator or for that matter, create with Acrobat Distiller. A PDF 1.4 file with live transparency exported from InDesign 2 will fail with a PDF workflow system that only supports PDF 1.3 and less. If such a system does allegedly support PDF 1.4 and you are getting failures with a PDF 1.4 file exported from InDesign, you should contact the system provider immediately. They are responsible for supporting you, not Adobe. It may be that they have some serious problem with the code they add to the system, modifications they may have made to Adobe code, or in fact your problem can be traced to a bug in Adobe code in which case, they will follow through and get a fix from Adobe. Hopefully, that helps explain this a bit. Please advise if you need further explanation. - Dov
Re: Adobe CPSI
Author: Trajan
Date: Fri, 19 Sep 2003 19:09
Date: Fri, 19 Sep 2003 19:09
13 lines
2115 bytes
2115 bytes
Dov, Thanks for your detailed response. I'm starting to understand this a little more clearly, but still have a long way to go toward reaching a real understanding (my eventual goal). (1) You wrote: "creating a PostScript file and distilling" does NOT make a more reliable PDF than any other method. This is especially true with regards to InDesign's "Export PDF" function which produces highly reliable PDF. Well, I and many others can only speak from experience, that many, many times we've tried Exporting PDFs from ID that are ripped incorrectly but work beautifully when the same file is postscripted first then distilled. I have no explanation for this. Heidelberg strongly recommends this, but of course their recommendations are built on the assumption that you are using Quark 4 or 5. My remaining questions: 1. Is it necessary to have a RIP to interpret PS? If not, how is the code rasterized (eg, for a laserprinter)? 2. How is the generation of "generic Postscript" different from any other kind? And what do you call the other kind..."regular Postscript"? 3. This was in my first message and I'm very curious to know its answer: Is it safe to assume that postscript code for an imagesetter must, by design, have a higher degree of complexity than code for a PS 3 laserprinter? Therefore the CPSI's parser and the RIP perform many tasks with the code that the laserwriter's driver just ignores?
Re: Adobe CPSI
Author: Trajan
Date: Mon, 22 Sep 2003 13:54
Date: Mon, 22 Sep 2003 13:54
5 lines
1178 bytes
1178 bytes
To answer your first question, no, my RIP doesn't need to be updated. I am using an Adobe Extreme RIP that is exactly one year old. It was built for a PDF workflow. As for the notion that distilling from a postscript file is "puzzling," I would suggest that thousands of prepress operators would probably beg to differ. Look how many of them offer this advice in these forums every day. They do so because it works. Is there such a thing as "generic Postscript"?
Re: Adobe CPSI
Author: Aandi Inston
Date: Mon, 22 Sep 2003 14:43
Date: Mon, 22 Sep 2003 14:43
12 lines
1216 bytes
1216 bytes
> They do so because it works. I'd like to analyse the cases where it isn't working. Though, to be fair, I don't have time. > >Is there such a thing as "generic Postscript"? There is no formal definition of such a thing. It could mean a variety of things. What do you understand it to mean? Aandi Inston
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads