EX 180 vs. EX-i 180

[EEM]

Hello everyone,

Can someone please help me understand what does 'Not Included' mean against 'APPE' and 'PDF/X Output Intent' in the (attached) list of features comparison of the external and bustled Fiery?

Thanks in advance!

 

[Puch]

The embedded Fiery version doesn't have the APPE (Adobe PDF Print Engine) option, which means it can't reliably handle non-CMYK, internally tagged PDF content. For example PDF/X-4 files can have both sRGB and AdobeRGB images embedded in them, and on top of that, an SWOP Output Intent. In advanced workflows, it's the DFE's task to normalize all the tagged graphic and properly flatten them into the Device CYMK (in my example, SWOP) colorspace. The embedded Fiery best fed with flattened, CMYK+spot data. In this case you must handle all the PDF normalization and flattening before loading the document into the DFE.

 

[EEM]

The embedded Fiery version doesn't have the APPE (Adobe PDF Print Engine) option, which means it can't reliably handle non-CMYK, internally tagged PDF content. For example PDF/X-4 files can have both sRGB and AdobeRGB images embedded in them, and on top of that, an SWOP Output Intent. In advanced workflows, it's the DFE's task to normalize all the tagged graphic and properly flatten them into the Device CYMK (in my example, SWOP) colorspace. The embedded Fiery best fed with flattened, CMYK+spot data. In this case you must handle all the PDF normalization and flattening before loading the document into the DFE.

Thank you so much!

More questions:
Are there any ways to overcome mainly those two incapabilities of embedded server? e.g. installing the APPE Engine on the server etc. and if yes, what could be possible implications of it in all possible manner.

Thanks

 

[kdw75]

Thank you so much!

More questions:
Are there any ways to overcome mainly those two incapabilities of embedded server? e.g. installing the APPE Engine on the server etc. and if yes, what could be possible implications of it in all possible manner.

Thanks

You could just send PDF/X-1 CMYK files to the RIP. Having had lots of RIPs from the bustled to the top of the line on machines, I wouldn't ever consider the bustled. It doesn't save that much and the reliability is lacking compared to the external Fierys. The one and only bustled Fiery we had would need to be reset frequently because it would choke on files.

 

[Puch]

Are there any ways to overcome mainly those two incapabilities of embedded server? e.g. installing the APPE Engine on the server etc. and if yes, what could be possible implications of it in all possible manner.

You might buy the APPE as an upgrade option, for a fee - ask the system supplier. It can cost around 1000-1500 USD.

My only concern with APPE capable DFEs is that you see the fully normalized, flattened artwork only at the end, on paper. Imagine a crappy document (full with impossible situations, which will surely fail in print). If you start printing the problematic document, you either catch the errors and stop the production, or loose a lot of money. To circumvent the problem you might ask the client to approve the job on the machine, just before printing. IMHO they don't like coming anymore, there's no time for that.

The other option is to handle the normalization and the flattening way before printing, with a product like Callas pdfToolbox. This will reveal all the hidden problems early on, and you can send the processed PDF back to the client for a review and a correction. Basically you free yourself from the burden of approving the job.

As kdw75 said, sending a PDF/X-1a to the DFE is the best way to peace of mind. This is the kind of document which can be reliably processed even by ancient RIPs, DFEs.

 

[EEM]

You could just send PDF/X-1 CMYK files to the RIP. Having had lots of RIPs from the bustled to the top of the line on machines, I wouldn't ever consider the bustled. It doesn't save that much and the reliability is lacking compared to the external Fierys. The one and only bustled Fiery we had would need to be reset frequently because it would choke on files.

Thank you kdw75,
This I realised while researching as I have been for more replies. Your suggestion does help and it also confirms my insecurities about the embedded Fiery : )

You might buy the APPE as an upgrade option, for a fee - ask the system supplier. It can cost around 1000-1500 USD.

My only concern with APPE capable DFEs is that you see the fully normalized, flattened artwork only at the end, on paper. Imagine a crappy document (full with impossible situations, which will surely fail in print). If you start printing the problematic document, you either catch the errors and stop the production, or loose a lot of money. To circumvent the problem you might ask the client to approve the job on the machine, just before printing. IMHO they don't like coming anymore, there's no time for that.

The other option is to handle the normalization and the flattening way before printing, with a product like Callas pdfToolbox. This will reveal all the hidden problems early on, and you can send the processed PDF back to the client for a review and a correction. Basically you free yourself from the burden of approving the job.

As kdw75 said, sending a PDF/X-1a to the DFE is the best way to peace of mind. This is the kind of document which can be reliably processed even by ancient RIPs, DFEs.

Thank you Puch,
We have test driven Callas pdfToolbox and indeed that would solve many issues until we can afford an external Fiery. I have read your remarks on PDF/X-1 and PDF/X-4 in other posts and they too make sense and nicely close this discussion for me.

Thanks again!