• I want to thank all the members that have upgraded your accounts. I truly appreciate your support of the site monetarily. Supporting the site keeps this site up and running as a lot of work daily goes on behind the scenes. Click to Support Signs101 ...

To PDF or not to PDF

bob_5793

New Member
Hi

What is considered the best workflow to create a file for an Onyx RIP - driving a Large Format printer, creating a Postscript file or going the PDF route, I read about many problems with transparency.

At present we create a PDFX-1a:2001 by saving as from Illustrator or Indesign, this forces Transparency to be flattened and all colour to CMYK, which is what we want, although with an older Rip (we are retiring) we did experience some problems, simply rasterising files in Photoshop was the workaround. But that created monster files, slowing up the works !

As I remember, PS files were quite large, although we only ever used them for film separation output, never for Large Format work. As I remember back then PS'ing forced the driver to do certain things, that helped the Interperter - so it was a better workflow.

Today we receive PDF's and application files - the later being preferred as we can set bleeds and generally check over the file being PDF'ing, we often never know how a client has set up a PDF, just wondered if there was a more reliable method than creating a PDF, or are there ways we can improve the PDF workflow we have at present.

Thanks
 

bob_5793

New Member
I see that my version has the Global Graphics JAWS interpreter, can I assume problem being - the predominant page layout applications are written by Adobe (Illustrator and Indesign) - and when Adobe changes something in the way its applications write an output file ie PDF or PS - JAWS has to catch up and amend its code.

Have Onyx then ditched JAWS for the Adobe Interpreter ?
 
I see that my version has the Global Graphics JAWS interpreter, can I assume problem being - the predominant page layout applications are written by Adobe (Illustrator and Indesign) - and when Adobe changes something in the way its applications write an output file ie PDF or PS - JAWS has to catch up and amend its code.

Have Onyx then ditched JAWS for the Adobe Interpreter ?

Onyx uses both Jaws and APPE in their various products. A segment of the installed base uses Productionhouse/ Postershop/ RIP_Queue. All of these have used (and continue to use) Jaws.

Onyx Thrive uses APPE rather than Jaws.
 

AF

New Member
It is my understanding that APPE based rips use the Adobe APPE rip module for processing PDF files only (and possibly Adobe native files like .ps and .ai). All other stuff you send through the rip goes through the JAWS rip module.

I often rip 5 files at a time since my particular RIP (Colorgate) has 5 APPE licenses. I have not had any snags while doing this and since my rip station has 6 processor cores, it rips each file at full speed simultaneously. A real time saver. Something to consider when shopping for a new RIP and new hardware to run it on.
 

player

New Member
A huge relief after using Versaworks for the past 5 years and dealing with all the workarounds to get PDF's to print properly.

Could you explain the PDF issues you encountered with VersaWorks and some of your workarounds?

If this is too much of a threadjacking I could start a new one...
 

bob_5793

New Member
Yes, completely hijacked - no worries :)

On a related side issue, an above poster raised an interesting question, does Onyx 'Thrive' replace the likes of Rip Centre, Postershop and Production House - or are these still current supported products.

Back to the thread.

OK, should I assume PDF is the new black, no one PS's any more ? does Adobe use the same 'engine' to flatten whether saving a PS or PDF.

With regard to PDF's, with Onyx V10 using the Global Graphics JAWs interpreter, and in view that we have a discontinuity between the maker of the creator of the file submitted to the RIP (Adobe PDF, such as Indesign and Illustrator - we rarely come across other app's) and the Interpreter (Global Graphics JAWs) - where then is best to do the flattening, ie by saving a PDF/X-1a:2001 and letting Adobe do it, or keep Transparency Live and save a PDF with a later version, and let the RIP flatten.

One problem I am aware of when Adobe flattens (ie using the flattener when exporting a PDF from Illi or Indesign), it chops intersecting transparent objects up into 'atomic' regions, subsequent trapping software can then cause issues between these segments, adding unwanted traps. As we run a composite workflow for large format output, such problems with a separated and trapped workflow are not an issue for us.

If we save the PDF as a later version, keeping Transparency Live, and let the RIP flatten - is that not then subject to the JAWs interpreter trying to read correctly what Adobe has written into the PDF.
That is often, last resort solutions of rasterising a PDF in Photoshop prove 100% reliable - its all Adobe code.

Colour management can then add an additional layer of complexity for transparency, and again do you just remove that risk, and PDF/X-1a:2001, or run a colour managed workflow - and consequent live transparency - letting a non Adobe written software try and interpret it all.

I ask - as I ponder how good an Adobe desktop application is at flattening - as opposed to a high end RIP - with all the above in mind.

Thanks
 

AF

New Member
Get a demo of Thrive from Onyx and see for yourself how much greener the grass is with APPE and PDF transparencies.
 

bob_5793

New Member
Can I ask where you flatten, in the RIP (ie keep transparency live) or do you flatten when making your PDF's, and do you have a colour managed workflow - or do you keep all that out of the PDF, applying profiles prior to creating the PDF.

Thanks
 

AF

New Member
Can I ask where you flatten, in the RIP (ie keep transparency live) or do you flatten when making your PDF's, and do you have a colour managed workflow - or do you keep all that out of the PDF, applying profiles prior to creating the PDF.

Thanks

Do not apply output profiles prior to creating the PDF. Let your RIP do the output color management. Embedding the correct input profiles is important (sRGB, camera profiles etc) but output profiles are done in the rip. APPE will process the PDF and then at the last step it convert colors.

You can make some pretty ugly pdf files with multiple colorspaces, transparencies, gradients, embedded files and profiles and it just works with APPE.

For separations for plates, I have no advice. I haven't dealt with offset for 20 years. I imagine APPE would be ideal for PDF to plate since that is one of the major marketing points by Adobe and all the critical rips use it.
 

bob_5793

New Member
For the immediate and short term we are using generic profiles - we will look to profile our equipment very soon and use those profiles, but regardless, we receive many images with embedded profiles that are different to our working space, or have no embedded profile - we need to educate our clients - and ultimately provide downloadable profiles that they can use to convert and embed. Judging from current time pressures on turn round and the ability of the client to commit to using our profiles - I feel however we will go on receiving images (and documents) with the wrong profile from the majority of clients.

On a side note - we have always discouraged clients from submitting non CMYK images, another reason for them to use our profile and convert to CMYK prior to submitting files.

With V10 is it not better to get all your files to the same colour space (CMYK) before submitting to the RIP ... leaving files as RGB (or what ever color description) in a PDF, with blends, and with live transparency - I thought would be asking for trouble, APPE sounds very good if it resolves all those issues - but V10 is where we are at now, and want to find a work flow that is correct for that.

Creating separations added a whole layer of complication to an already complex task, and even more so now there is transparency and colour management involved - I wish we'd had internet forums back then !
 
Top