Home | Contact Us | Submit Troubleshooting Info | Search | Help


    Output | Software Solutions | Proofing | Color, Screening and Calibration | Scanning | Digital Photography | Consumables | POS


Plate separations from Prinergy do not show up in Print Console’s queues until each separation is processed

checkbox.gif (459 bytes) Tested     uncheckbox.gif (229 bytes) Not Tested


Applies to

  • Print Console 1.x
  • Prinergy 1.x, 2.0

Problem

What it looks like:

CMYK job comes in from Prinergy and appears in the PC Pending Queue. Only the job level and datasource level appear (no CMYK separation levels).

What happens when you process the job:

As the device and RIP become available, the job moves from the Pending Queue to the Active Queue. As the Plateworks RIP begins processing the job, the first separation (C) appears in the PC Active Queue below the datasource level. When that separation finishes imaging, the RIP begins processing the next separation (M), and that separation appears below the C separation. This continues until all separations for that job have been processed and output.

Why this is a problem:

A CMYK job will look the same as a CMYK+2 Spots job or an M job. User can’t determine how many separations are in a job until after that job has finished processing.


Workaround

None. This is actually normal behavior. See below for the permanent fix.

Background

Why this happens:

Prinergy is integrated to Print Console in two ways -- one for proofs, one for plates. When making proofs, Prinergy currently generates one TIFF file for each proof separation, those files are dropped into a Print Console hot folder, and the files appear as separate, single-separations “jobs” in the Print Console queue. A user must manually group separations together into one job, and then you can generate the proof. Thus, the separation content is known, since each separation corresponds to a file. The raster is actually sent to the Spectrum by TIFF D/L, not directly by Prinergy.

When making plates and film, Prinergy is integrated with Print Console in direct-output mode. The raster is not written to a TIFF file. Rather, Prinergy uses a software interface to Print Console to put a job in the queue. When Print Console tells Prinergy that the device is ready for raster, the Prinergy RIP sends raster directly to the device.

The technical issue is that the software interface for direct-output mode is old, dating back to the original platesetter control software, which was designed for one plate per job output. That interface does not allow Prinergy to specify the separation content when the job is queued. It can only specify the separation content as the job is output, one separation at a time.

This old software interface was kept in Print Console, TIFF D/L, and Prinergy for compatibility and schedule reasons. The deficiencies in this interface is are one reason (of several) that Prinergy makes proofs using TIFF files (other reasons lie within Prinergy itself). However, it works well enough for plate output, except that it does not allow for good GUI feedback in Print Console.


Permanent Fix

We are in the processing of fixing this GUI feedback issue, and a solution will be ready later this year, in GDAPI. GDAPI version 1.0 is already used by Prinergy to drive DOP. HDPP is also adopting GDAPI for input to their devices, and for integrating Delta to Creo devices in the future. Print Console 2.0 contains an early release of GDAPI 2.0, and it will be ready for workflow systems integration with GDAPI. There is not a specific date for official release of Prinergy / Print Console integration via GDAPI 2.0 yet, but it will definitely be after Drupa and likely towards the end of the year.

GDAPI 2.0 will be used for both plating and proofing workflow from Prinergy to Print Console, making the integration very tight (no more TIFF files through hot folders and manual grouping) and robust. And, GDAPI allows Prinergy to specify all the separation metadata and other job info for display in the Print Console 2.0 GUI. GDAPI will also replace CRI in the long run, and Scitex has responded positively to GDAPI.


Technical contacts
James Bredenhof, x5108
Michael Weber, x2336
Date submitted
February 25, 2000
Last modified
March 7, 2000

    Copyright © 2005 Creo Inc. All rights reserved. Confidential. Back to top.