Hi Marti, please see below. > Regarding CSA, I'm touching the code. Seems it would be easier if lcms > generates only the dictionary without the %% comments and the > /Current exch /ColorSpace defineresource pop. The CRD is untouched. > Anybody has code that will be broken with that? PS generation is still a > new feature and hope changing this would have no bad effects.
I think this is OK. You can't know anyway how people want to use the CSA and CRD, so I also think it is best to create the CSA or CRD only. > > 2. On the resulting print, the whole imageable area surrounding the > > printed objects - which should actually be white - comes out as a very > > light gray with a light blue cast (or should I say very very light > > blue?). Any ideas, what could be wrong? > > This may be a bug. I'm currently trying to reproduce it. Of course it is also possible that I did use the CSA/CRD wrongly (see my previous posting what I'm doing) or that there is a bug, but not in LCMS, but in ghostscript. I'll also continue investigating. > > 3. BPC. Unfortunately the CRD generated by icc2ps does not perform BPC. > > I think I can't live without BPC any more for printing :-) > > Marti, may I put a "-b" option for icc2ps on my wishlist? I think the > > TransformPQR basically could perform a BPC, as the postscript > > interpreter also passes the src and dst black points to this function, > > doesn't it? > > Ok, this is what has taken me time to think. Seems there is no easy way to > > do so. Let's examine the facts. BPC is a compensation from source to > destination black points, and as such, only makes sense when creating > transforms. > > Then, using CSA and CRD is same as delegating the transform creation to PS > > interpreter, so, it should be the interpreter who applies BPC. We cannot > apply BPC to CRD since there is only a CRD for each page, but it can be > multiple CSA, one for each PS element. And nor to CSA, since there are may > > be CSA already embedded in the document. > > Any idea on how to do that? I must admit that I did read the PLRM only briefly. I fully agree, that the CSA is the wrong place for such a transform - it just describes a color space, but not a transform between color spaces. However, I think that the CRD might be the right place for it. Quoted from PLRM, chapter "7.1.2 Type 1 Color Rendering Dictionary": "[...] 2. Adjust the X, Y, and Z values to account for differences in the diffuse white and black points of the source and the device. This transformation attempts to satisfy the requested rendering intent, according to the MatrixPQR and TransformPQR entries of the color rendering dictionary. The diffuse white and black points of the source are given by the WhitePoint and BlackPoint entries in the color space dictionary; those of the device are given by the same entries in the color rendering dictionary. If the corresponding WhitePoint and BlackPoint entries in both dictionaries are equal, the MatrixPQR and TransformPQR entries are ignored and this step reduces to the identity trans-formation." My interpretation is, that MatrixPQR and TransformPQR in the CRD *are supposed* to perform a CAT and - if desired - even a BPC in order to account for differences in the white and black points of the source (-> CSA) and the device (-> CRD) color space. In order to enable the TransformPQR to do that, the PS interpreter also passes *both*, source (from the CSA) and destination (from the CRD) white and black points as function arguments to the TransformPQR function contained in the CRD. So IMO a CSA just describes a color space, but a CRD describes both, the device color space and the whitepoint/blackpoint mapping function from an arbitrary source color space (with variable WP&BP) to the device's white and black point (-> CAT + BPC). I don't expect that the BPC can be precalculated in the CRD, but I think, that the TransformPQR could perform the BPC at runtime, based on the src BP passed by the PS interpreter to the function and the well known device BP, which is also recorded in the CRD. Concerning multiple CSAs in a document, I think it does not matter: I guess there is not a single, static CSA->CRD transform, but the PS interpreter dynamically creates multiple transforms, one for each CSA/CRD pair encountered, and whenever the PS interpreter renders a specific CIE-based color it selects the appropriate one of these transforms, depending on the CSA associated with the color being rendered and the currently active CRD. Best Regards, Gerhard -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualit�tssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Lcms-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lcms-user
