How might Rips differ when processing a PDF?

[Skinflint]

What actually happens to a PDF when being interpreted by a RIP?
Does anyone have the inner workings down to a point that you can explain the process?

 

[Stephen Marsh]

What actually happens to a PDF when being interpreted by a RIP?
Does anyone have the inner workings down to a point that you can explain the process?

I am not a programmer, developer or engineer – which is the level you seem to be asking for.

I believe that there are three broad areas to this discussion:

1) PDF file input: which may alter the original PDF through a “normalization” process, or this could be bypassed and the input file is not changed in any way

2) RIP architecture differences:
–Licensed PostScript Interpreter Levels I/II/III from Adobe (CPSI)
–3rd Party PostScript Interpreter Levels I/II/III
–Licensed native Adobe PDF Print Engine (APPE)
–3rd Party native PDF processor

3) Even between two different RIPs that both use APPE, there are different licensed versions of code, there are different OEM configurations of the base licensed APPE code and then there are user configurable options for the RIP or Workflow setup that may differ between two “similar” APPE based systems from different manufacturers.


Stephen Marsh

 

[Stephen Marsh]

Skinflint, from your other post, a good way to identify differences in rendering between two systems is to run some test forms through each and compare. You may find differences between the expected test file results and also differences from RIP A vs. RIP B. Some of these variances may be corrected with the correct setting, such as enabling honouring of incoming overprint commands.

http://www.gwg.org/download/test-sui...-verification/

http://www.gwg.org/download/test-sui...-output-suite/

http://www.eci.org/en/downloads (Altona Test Suite)


Stephen Marsh