• Best Wishes to all for a Wonderful, Joyous & Beautiful Holiday Season, and a Joyful New Year!

Defining and embedding screen angles in a PDF

schenkadere

Well-known member
How is everyone defining screen angles going to a PDF RIP. I am using Navigator 8 but still create postscript and define the angles in the print dialogue of Illustrator. I would like to be able to define my angles to be maintained in the PDF and simply drop the PDF to a hotfolder.
 
I always thought that was what JDF was for.

( wink )

I think you may not get many replies here - since nobody is defining screen angles going to a PDF RIP within the PDF file. Do you really change the angles that much ? Why can't you set this in the RIP ?

- the only time we needed to manage screen angles at the file level - is in the very rare situation where we had to manage spot colors tints that overprint other spot color tints ...

I do not think there is a method to 'add' what screen angles you would like used for each color in a PDF that would then be 'preserved and applied' within a Global Graphics RIP ( Harelequin )

I think you are 'stuck' doing what you are doing now - that is, settinge angles when printing separations to PostScript

Adobe Community: Bring Back Line Screen & angle settings - Please - with sugar on top.
 
Can't really set it at the RIP when you're not consistently using the same spot colors, ex. corporate colors. We can actually use Esko's Ink Manager within Illustrator but the downfall is that you must save as a normalized PDF which is flattened...I'd rather not do that. But, yes, we change angles quite often. We are a folding carton printer so we don't often run straight CMYK + spot...usually multiple spots.
 
Right...the decision is being made in Illustrator, but then going to postscript. What's the point in having a PDF native RIP and being able to stay with PDF throughout the workflow if you can't have the same control as a PS RIP. The Harlequin screening set up is fine, but again, you would have to define an enormous list of spot colors and be sure they are named exactly the same for every job....unless I'm missing something.
 
I think I started out saying "I always thought that was what JDF was for." - which it is.

What we need is a JDF file that enables you to express the many things that have no real business in a device independent depended PDF file.

But that does not seem to be happening.

But, there is hope !

GWG Presents PDFs for Packaging Session at PRINT '13/CPP - Ghent Workgroup

The Future of PDFs for Packaging - Ghent Workgroup

The Future of PDFs for Packaging - Ghent Workgroup

Hope this helps ( or at least, gives you hope ! )
 
IDK...you can do it with a PS...you're figure by now you could do it with a PDF.

PostScript is a programming language that was developed to control printers AND also provide a way to explain things like shapes and images. PPDs were required. Printer drivers were required. That was how you could make color separations - by selecting a device and printing to it. That is not what you are doing here. You are sending a device independent document to 'some system' - and the PDF would be managed by that system. PDF was designed on purpose to not need device settings inside it, so i could print it with the device settings i require ( which might be different than yours ) - so, while I appreciate what you are wishing for, no one does it that way. Everyone takes incoming PDF files and sets up a system to process them.

Adobe is not in the package design prepress software business - Esko and PaSharp are - and they charge a pretty penny to make the tools prepress folks need for the package design vertical - because - as you can imagine - there are not a lot of folks who need nesting step and repeat and complex trapping for flexo.

Perhaps you could look into CxF - but - it seems to be a bigger issue than that.

Solutions for Packaging Prepress Professionals - Esko

Founder Electronics - PaSharp

What can I say man - you can complain all you like, but that is not what PDF is all about - the GWG is working on solutions, but as of today, it is just a bunch of draft application notes for developers. Until there are a stable specification and a suite of agreed upon test files for RIP developers to process, we are still in lip flapping mode.

See slides 25-27 ( some folks say CxF will be where the screening details go, as they quickly becomes embroiled with how color behaves )

See slides 29-47 - that explains that it is just not screening that we need to exchange in ( or perhaps 'within' ) a PDF..

http://www.gwg.org/wp-content/uploads/The-Future-of-PDF-for-Packaging_GhentWorkgroup_-Print-13.pdf

Hope that helps.
 
IDK...you can do it with a PS...you're figure by now you could do it with a PDF.

It is the PORTABLE Document Format. Note the first word - PORTABLE.

Screen angles are anything BUT portable. As such, they don't belong in PDF - which is why they aren't there after 20 years. (and never will be).

As Michael said - if you want angles with PDF - that's what JDF (was supposed to be) for.
 
Screen angles are anything BUT portable. .

Yes, I didn't really want to go there - but - even if the OP assumed that they could assign a 105 angle to some spot color and 45 to another - and said they wanted 175 line screen, and said "oh, please rip it at 1200" - that is technically different that 2400 ( slightly different screen angle result ) - because - well - you can't actually embed the screening algorithm.

So, it was a dumb idea even in PostScript ( if you were sending PostScript as a file to 'some other location' ) - and the only way it 'worked' is when you were sneding PostScript using that device settings, that device PPD, yada yada...

So, how that is different that set this all up in a RIP is beyond me. Screen angles are a device dependent setting - either send it as JDF, or set it at the device. Does not belong inside a PDF.

Of course - you can create and send this silly types of PDF file where they are ripped and screened already;

https://www.dropbox.com/sh/9pg9gsrqc0nhmgp/_2ZDeBaUUX/004_WontonRipTrapRasterScreened.pdf

but you will not enjoy the processing time hit.
 
Heidelberg's PDFToolbox has a screening selector with which you can set screen type, angle and more. You can choose to set this for all objects in the PDF differently if necessary.

The embedded screen angles in the PDF should work with Global Graphics RIPs as well. The screen type is Heidelberg proprietary and will most likely cause a warning or error.

As far as I know, the screening selector tool does not need a license to work, so if you can get a trial of PDFToolbox from Heidelberg you can test it yourself.
 
Heidelberg's PDFToolbox has a screening selector with which you can set screen type, angle and more. You can choose to set this for all objects in the PDF differently if necessary.

The embedded screen angles in the PDF should work with Global Graphics RIPs as well. The screen type is Heidelberg proprietary and will most likely cause a warning or error.

As far as I know, the screening selector tool does not need a license to work, so if you can get a trial of PDFToolbox from Heidelberg you can test it yourself.

Thanks...that's what I'm looking for. As I said, I can use the Esko Ink Manager to set the angles, but the downside is having to save a flattened, normalized PDF to hold the angles. Does the Heidelberg force you to save a flattened PDF?
 
Heidelberg's PDFToolbox is quite nice. You can do a lot with it.

To your original question - forgive my ignorance, I'm not aquainted with Navigator. You should be able to set the default angle for spots and then have subsequent spot colors cycle through the other angles that would normally be used. For example, spot 1 might screen at 45º then spot 2 at 75º, spot 3 at 90º (or 60º if you run that variant), et cetera.

Would that accomplish what you need? If your RIP doesn't allow you to do that, I'd be surprised.
 

PressWise

A 30-day Fix for Managed Chaos

As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line.

“We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month.


Learn how…….

   
Back
Top