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

CMYK 2 CMYK (Device link) and PDF/X-4

Magnus

Well-known member
Hi all!

Is there any CMM (CMS) out there that is fully compatible with PDF/X-4 files?

I'v tried a few, but non of them seams to handle "live trancparancy" correctly..

Please let me know! :)
 
I bet someone who knows the answer to your question would also know the answer to mine, but what is CMYK 2 CMYK, CMM, and CMS? Wait I'll take a guess... "S" stands for System and "C" stands for Computer?
 
CMM (color management motor) CMS (color management system).

Device link profiles is a profile to convert a document from one CMYK-profile to another, with certain customized rules. Keep pure CMY and K for instance. Very useful for converting an Fogra39 PDF to you press-profile for instance. Some of this software also have some kind of ink-optimization.

Example of products: ICEserver, Binuscan CMS-server, GMG ink optimizer, Alwan color hub etc..

Theres also built in Device link support in some Prepress Workflows.

But I haven't yet come across any software which fully supports live transparence which is "allowed" in PDF/X-4.
 
Callas pdfToolbox, pdfToolbox Server, CLI and SDK can all apply device link profiles. So can PitStop Pro, not sure about PitStop Extreme.

I think you'll find pdfToolbox will work for what you need. Depending on how your workflow is structured once the links have been applied to a PDF/X-4 you can flatten the transparency. Give it a shot. I'd be happy to apply some links for you for testing if you like.
 
Ok, I'll try to give you a simple example of what I would like to do:

PDFX/4 (all CMYK Fogra39 content) convert everything to KBA_P2_175_v1 (one of our press-profiles) lower TIC to 270%. Keep primary and secondary colors, keep 100%.

When I do this in my current workflow I wont get the same result converting a PDF with transparency compared with an PDF/X1-a.

It would be great if I can send you an simple example!
 
The difficult part is how to handle overprint when reducing colour. Should it be emulated? Should the black be kept? Do you do it in several stages, first reduce TAC on all placed images, then look at how it would emulate overprint?

The problem with transparency and still having it live when reducing colour is that of blending.
If you mix two colours. CMYK 40 30 30 0 and 0 0 0 40 wich look very similar visually (rounded numbers to make things simple)
Using screen mode you will get 0 0 0 0.
Now if you convert those two patches to any level of GCR the 40 30 30 will contain black, meaning that the blend mode will no longer give 0 0 0 0 but 0 0 0 x where x is the value of black generated.

This is just one example.
Also consider a black text on a photo? Should the ink be reduced, or should the appearance of a black text with overprint be emulated. When should trapping be applied?

So keeping prepess knowledge away from designers and telling them just use FOGRA 27 and we take care of the too much ink with a colour converter isn't going to solve every problem, it does in fact introduce a whole new series of problems.

I have just raised a small example, even if it may be extreme to show that the complexity is much more that we may imagine. In most cases it is therfore better to do Ink Reduction or CMYK to CMYK conversion after flattenig, since it will have least visual surprises on the printed result.
 
In most cases it is therfore better to do Ink Reduction or CMYK to CMYK conversion after flattenig, since it will have least visual surprises on the printed result.

I just had a file over the weekend that goes against that. In my example, a drop shadow falls over some black text overprinting a light yellow gradient background. When flattened, some of the text is converted to raster - some of the letterforms are split between raster and vector. At that point it is no longer straight black type, but part of an image and is subject to color transformation.

See the attached screen grab. Can you see how the number "7" is two different colors? Though an isolated incident, this points to a flaw in that workflow. I prefer to do everything BEFORE any flattening occurs - color transforms, trapping, everything.
 

Attachments

  • Picture 1.jpg
    Picture 1.jpg
    13.5 KB · Views: 228
Last edited:
I don't see how that would go agains it what I said.

How would you do a CMYK to CMYK conversion on that image anyway? My whole point is that CMYK to CMYK conversions and transparency don't go well together.
In your example I would say the error is transparency above text. If flattened then the colours before CMYK conversion are the same, even if one is image and the other is type? Should not the colour conversion honour that? Why are you handling colour different for images and type/vector? There are lotts of examples where customers match a colour in vector and pixel, I think it would be wrong to treat them different.
 
Ok, I'll try to give you a simple example of what I would like to do:

PDFX/4 (all CMYK Fogra39 content) convert everything to KBA_P2_175_v1 (one of our press-profiles) lower TIC to 270%. Keep primary and secondary colors, keep 100%.

When I do this in my current workflow I wont get the same result converting a PDF with transparency compared with an PDF/X1-a.

It would be great if I can send you an simple example!

Magnus, I sent you back the test files that I processed. I used TGLC device link profiles (FOGRA39 to FOGRA39, 240 TAC). Let me know what you think.
 
…In your example I would say the error is transparency above text.

Yes, you are correct.


If flattened then the colours before CMYK conversion are the same, even if one is image and the other is type? Should not the colour conversion honour that? Why are you handling colour different for images and type/vector? There are lotts of examples where customers match a colour in vector and pixel, I think it would be wrong to treat them different.

The example shown is flattened.

No, no, Lukas. Unflattened you have black text overprinting the background - as such the black text is not subject to change using a device link. Flattened, you have an area of raster data that is black + the background color - it will be converted during the ICC color transform.

To Magnus' original question, I don't think that any of the CMMs are incompatible with PDF/X-4. It sounds like he's having an issue with the transparency blending space.

Oh, and I agree entirely, Lukas - vector and raster data MUST be handled EXACTLY THE SAME during color transforms. The difference in my example is between an overprinting one-color element and a 4-color raster element.
 
@ Matt, thanks for helping me with the testfiles, but could you convert the same PDF:s from one profile to another, lets say Fogra39 to Fogra47, or similar. Then the problem Im refering to might become visible.

@ Apollo (and all others) I'll post the files I sent to Matt here and a screenshot to try to explain the problem. It's really simple.

Here's the testfiles (and my converted files): www.magnussandstrom.se/download/transparency_test.zip

Here's the screenshot: www.magnussandstrom.se/download/screen.jpg

Would love to see your results.
 
FOGRA39 to "x", sure. I don't know that I have a FOGRA39 source device link but I can make something work.
 
FOGRA39 to "x", sure. I don't know that I have a FOGRA39 source device link but I can make something work.

Matt, you have the exact same "problem" as I. The two PDF:s aren't the same color and the PDF/X1a is the correct one..

In a perfect world the two files would look the same after conversion. This is why (in our system) we check for transparent object and "normalize" the files to 1.3 PDF:s. But normalizing a PDF isn't totally safe, sometimes we get strange effects/errors..
 
Magnus,
Let me know how I can get these files to you. I ran your files through my system, and because of the nature of the colors involved got no change on the PDF/X-4 file. The PDF/X-1a file did change CMYK values, but I think you would agree that the result is acceptable.

Now, to better test this we need to build a similar file with some 3-color tints overlapping.
 
Hi Apollo, I send DM to you with my email-adress.

Magnus,
Let me know how I can get these files to you. I ran your files through my system, and because of the nature of the colors involved got no change on the PDF/X-4 file. The PDF/X-1a file did change CMYK values, but I think you would agree that the result is acceptable.

Well the PDF/X-4 should change the same way the PDF/X-1a do, otherwise the color is wrong. Of course the GCR is allowed differ but the color should look the same in print. Otherwise I wouldn't say that the system is PDF/X-4-compatible.

Now, to better test this we need to build a similar file with some 3-color tints overlapping.[/QUOTE]

You can send me such files to my email if you want.

Conclusion: We have still not seen any system that handle transeparance the correct way, right? :confused:
 

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