• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Simulating with a dLink in iQueue
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simulating with a dLink in iQueue


  • Subject: Re: Simulating with a dLink in iQueue
  • From: Henrik Holmegaard <email@hidden>
  • Date: Thu, 11 Mar 2004 13:16:22 +0100

"Treetop Publishing, Inc." <email@hidden> writes :

>Yes, this is so I run a Queue for this purpose first. But what I don't
>understand is why IQueue has Device Links for CMYK (Lab and Raster), RGB
>(Lab and Raster), and Grayscale, it you are supposed to Normalize the file
>into one colorspace.

An ICC device link cannot color manage a CIEL*a*b* object and there are no device link filters for CIEL*a*b* in iQueue. There are only device link filters for device color spaces, CMYK, Gray and RGB.

Let's to go over the terrain again as many, many users and developers have problems understanding device links. This is the reason they keep asking for device links and keep implementing device links wrong.

Given the above, here we go :

When you work with PostScript there is _no_ support for the ICC profile file format. This way the ICC approach to object level color management is disabled, because ICC profiles are ignored, as the manual explains.

So you need a filtering mechanism that goes, Hey, this is CMYK vector, let's assign MyCMYK_1, Hallo there, this is CMYK raster, let's assign MyCMYK_2 or should we also assign MyCMYK_1 and so on and so forth.

All the color servers have worked this way, first LogoProof, then BatchMatcherPS and now iQueue, as you can read in the List archives. It is always true for a PostScript workflow that all CMYK must the _same_ CMYK.

If it is not the _same_ CMYK you cannot meaningfully assign a source ICC profile, and you need to assign a source profile in order to get the data in the connection space and out the other side as matched device values.

If you work with PDF 1.3+, EPS, JPEG and TIFF there is support in these file formats for embedded ICC profiles. (For PDF and EPS there is also support for embedded PostScript Color Space Arrays which are ignored, as the manual says.)

As long as you work with PDF 1.3+ (let's forget EPS which is a legacy format), iQueue will read ICC device profiles in incoming PDF documents, apply the rendering intent you have chosen and convert the channel values in the data objects.

But if you ask iQueue to match file formats which support ICC device profiles, but using ICC device links instead of ICC device profiles, you are in exactly the same situation as when you are in a PostScript matching situation.

In an object level device profile workflow, you can have Source CMYK_1, Source CMYK_2, Source CMYK_3 . . . Source CMYK_9 which all match to Destination CMYK_10, because all the embedded source profiles are applied.

In a device link workflow you do not have object level color management, because Source CMYK_1, Source CMYK_2, Source CMYK_3 . . . Source CMYK_9 are ignored. Therefore, you must make them all CMYK_9 _before_ you place them in the layout.

Now you can use a device link which is built so that the first space in what is called the "profile sequence" is CMYK_9 and the last space is CMYK_10. You then say, I know that all my CMYK is CMYK_9, so my dLink will get me to CMYK_10 even if embedded CMYK profiles in the incoming data must be ignored as per the ICC Specification.

>Thus, these device links replace your source profiles for these
>colorspaces. So, you can still Queue up and mixed space PDF.

Yes, e.g. all your CMYK vectors must be CMYK_9, because all CMYK vectors must be color managed by one and the same CMYK vector dLink filter that assigns all CMYK vectors the value of CMYK_9 and converts them to CMYK_10.

You can still have another CMYK for CMYK Images, but all CMYK images must be the _same_ CMYK. This is also true of RGB images and vector graphics and Gray images and vector graphics, of course.

>If this is so then you only need to standard on these (whatever your choice
>for building the DLP's) source spaces in your layout program, e.g.,
>Indesign. All RGB will be sRGB; all CMYK will be USSheetfed.....

Sounds like you've got the hang of it.

Thanks,
Henrik
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.


  • Prev by Date: Re: Maximum Chroma vs. Maximum Gamut
  • Next by Date: Re: Unicode WYSIWYG - WYSIWYS campaign
  • Previous by thread: Re: Simulating with a dLink in iQueue
  • Next by thread: [OT] The File contains Info Data which cannot be read and has been ignored
  • Index(es):
    • Date
    • Thread