Navigator 8 Ripping CTs at different angles than LW

[choneysett]

I am feeding a PDF to our new Navigator 8 rip. Screen angles are defined in the metadata of the PDF which the RIP appears to read fine. All spot colors, regardless of in a CT or a LW read fine. But the process colors are correct in the LW, but incorrect in the CT (which comes from a Photoshop DCS2 by the way). Any ideas why these 2 would be ripping separately?

[DonBlock]

Is the Color Space set to override angles? Are you specifying particular angles that you are not getting, or do you want the default angles of the RIP?

[choneysett]

There are NO overrides set in the RIP. All of the angle information comes from XML data defined in the PDF. The LW is reading those angles fine, but the CT is ripping at a different angle. The spot colors in the CTs are ripping fine as well. Just for a test, I changed the default angles on the RIP, even though I do not have override angles checked. The change in the default RIP angles had no change in my result.

[GinSu]

Is the option to include halftone screens checked when the DCS2 CT is saved from PSD? If so, this can override RIP settings.

[choneysett]

Include halftone screens is never checked when saving the CTs. Too bad too because that would have been an easy fix!

[DonBlock]

If you don't turn on to override angles on the RIP, you can make them anything you want and it may not have any effect. The only answer is that there is line screen information that is embedded i the CT. Set the angles that you want on the RIP and check the box to override the angels. You will get what you ask for.

[choneysett]

The purpose of this workflow in the RIP is to accept different screen angles as they are defined in the PDF. So setting the screen angles to override would defeat the purpose. The angles are going to be different for different jobs.

Further information has come to light as well. What I was originally told was Photoshop DCS2, it turns out is actually a Photoshop .PSD file. The DCS2 file seems to be running through the RIP fine. I have some more testing to do, but it appears to have issues with the .PSD file that is embedded in the PDF.

[maxon]

The purpose of this workflow in the RIP is to accept different screen angles as they are defined in the PDF. So setting the screen angles to override would defeat the purpose. The angles are going to be different for different jobs.

If your work is offset printing I don't see any good reason for not having the halftoning done in rip. I normally tend to override most of the screening params if not all, not only as good habit but also for consistency sake. Why would you allow incoming files to define your color sep?
I don't remember having seen any strong reason for fiddling with angles apart from curiosity, I played with halftone libraries along the years, Agfa balanced, RT, Crosfield Adobe CPSI, not to mention HPS since version 3.3 or 4.1.
Perhaps 99.99 of all offset printing in AM screening can (should ?) be normally reduced to the two families we all know, nominal-0 and +7.5. ...Or am I missing something here.

[choneysett]

The reason the files are defining the angle instead of the RIP is we are ripping files to generate 1-Bit TIFFS to go to other printers. This is for a packaging workflow for which we are the pre-press house. The printers we are supplying files to want the 1-Bit TIFFS, but we do different screen angles for different printers, not to mention different angles for different combinations of spot colors.