I am attempting to convert a pdf document that contains a gradient from CMYK to RGB using -dUseCIEColor option with the / ColorConversionStrategy set to /sRGB. As a result, the file size increaes dramatically One of our test files increased from 104K to 34MB. The file renders correctly in a Acrobat Reader and GSView, however, it takes an excessive amount of time. The output pdf files are intended for online use, therefore, the larger output is unacceptable. Here is the command I am using to render the PDF: gswin32c.exe -dSAFER -dNOPAUSE -dNOPAGEPROMPT -dSHORTERRORS -dBATCH - sDEVICE#pdfwrite -dPDFX#true -sOutputFile#output.pdf -f 000002.joboptions input.pdf The contents of 000002.joboptions are: ----Start File---- << /ColorConversionStrategy /sRGB >> setdistillerparams << /HWResolution [1200 1200] /PageSize [612.000 792.000] >> setpagedevice ----End File---- With the -dUseCIEColor set, GS transforms the gradient into a colorimage: colorimage s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-! s8W-! ... I retrieved the ps output using this command. gswin32c.exe -dSAFER -dNOPAUSE -dNOPAGEPROMPT -dSHORTERRORS -dBATCH - sDEVICE#pswrite -sOutputFile#output-ps.ps input-gradient.pdf If -dUseCIEColor is not specified, the pdf converts correctly; the file size is acceptable, render speed in the viewer is good, and all images are converted to RGB. However, the color translation is poor and the output in regards to color is unacceptable. Please let me know if anyone knows a way to resolve or workaround this issue. Thanks, Ralph
Please attach the input.pdf so we can look into this. If you wish, you can 'Edit' the attachment after you attach it and mark it as 'Private' so only Artifex staff can access it. I've fixed the 'Component' to PDF writer (instead of PDF Interpreter). Once we have the file and have duplicated the issue, we can assign it to the correct person.
Created attachment 4517 [details] Input File with Gradient Attached is an example input.pdf discussed in this bug.
I have posted the input file. Please let me know if you need any additional data. Thanks for the quick response. -Ralph
I was able to duplicate the problem of creating a very large PDF file from the attached file using: gswin32c -dUseCIEColor -sDEVICE=pdfwrite -o x.pdf -c "<< /ColorConversionStrategy /sRGB >> setdistillerparams" -f input.pdf
Hmm... Setting the resolution to 1200 is inappropriate for a PDF file intended for online use, the conversion to image takes the resolution into account, which is why the output is so large. You can reduce the file size by reducing the resolution, if you intend to print this at 1200 dpi you can probably reduce the resolution to 300, which will result in an image 16 times smaller than at present. If you don't specify UseCIEColor, the blend will be retained in (not converted to) RGB. I'm surprised that colour fidelity is critical in an online document, what are you using for a DefaultRGB colour space array ? The reason that the blend is converted to an image, is because its hard (and impossible in the general case) to convert a function which takes a single parameter and returns an RGB colour into a function which takes the same parameter and returns the 'same' colour in an arbitrary CIE space (which is what UseCIEColor is doing). The best that can be done is to convert the original function into a sampled function, by sampling the final CIE colour space and using that to generate the CIE colours for the gradient. This will *not* work for type 1 (function based) shadings at all, and will give different answers to the image for other shading types. Figuring out how many samples to take (unsampled values will have to be interpolated) is going to be interesting. I'm altering this to an enhancement, because the action at the moment is as expected (so it isn't a bug), and produces a reasonable result even if it is less than optimal.
Ke, Thank you for your response. You have provided me with a viable solution. I have reduced the resolution to 150dpi (via "-r" option) and the output is perfectly acceptable. I did not realize that the resolution of the rendered gradient was producing 1200dpi output. We definitely do not want that for online. I falsely assumed the resolution was inherited from the passed in Distiller settings. My sample excluded the Distiller image resample settings because they didn't appear to have any effect which they do not. Setting the "-r" option produces perfectly usable output. Thank you again for your help in resolving this issue. Best, Ralph
Sorry to answer a 4yr old bug, but i have the same problem. I need to do a CMYK to RGB transformation for mobile device. My PDF contains multiple gradiants that are tranformed into "drawings". The result is very ugly, file are large and rendering take too musch time. Can someone tell me if it's possible to ignore this type of filling when doing this conversion ? Or maybe a gradiant to PNG (like popple/GS do when doing pdf>ps>pdf conversion) ? Thanks
(In reply to comment #7) > I need to do a CMYK to RGB transformation for mobile device. My PDF contains > multiple gradiants that are tranformed into "drawings". The result is very > ugly, file are large and rendering take too musch time. > > Can someone tell me if it's possible to ignore this type of filling when doing > this conversion ? Or maybe a gradiant to PNG (like popple/GS do when doing > pdf>ps>pdf conversion) ? Please read comment #5, using a lower resolution should be perfectly acceptable on a mobile device. The code *already* does a conversion to an image, that's why the output is large. You cannot convert to a PNG as PNG is not a supported image format in PDF (or PostScript for that matter). Ignoring the gradients would be a 'bad thing' as the result would not be correct.
Created attachment 9038 [details] Original PDF test case
Created attachment 9039 [details] CMYK to RGB transformation
(In reply to comment #8) I attached two files where you can see that gradiant are not transform into PNG but into PDF script drawing (line by line approx !). I have an option to have an image, I'd love to use it :).
(In reply to comment #11) > I attached two files where you can see that gradiant are not transform into PNG > but into PDF script drawing (line by line approx !). I have an option to have > an image, I'd love to use it :). Its not the same problem, as you already know because in your case the file does not decompose to a bitmap. Please don't lump 'similar' problems into existing bugs. Your original shading is in DeviceRGB and does not need to be converted to RGB at all. If I simply run a conversion here it is *not* converted. So there must be something about the command line you are using (which you haven't given) which is causing this. In your case the file contains (spurious) transparency declarations (because the file has been produced by Cairo). and I presume this is causing the decomposition into rectangles, but it doesn't happen for me.
For shadings of this type, when converting to a different colour space, pdfwrite now samples the input colour space, converts the samples to the required output space and writes a function to map the original input to the corresponding required output components. In short it now converts a function mapping values to colour samples in a given space to a function mapping values to colour samples in a different space. For me this results in a file 30% smaller than the original supplied file, and the results are indistinguishable from the original (because the image on page 1 is a JPEG there are the usual problems caused by re-encoding to JPEG). The file supplied in comment #7 did not cause a problem at the time, and still does not cause a problem with any command line I can concoct. Possibly there is a genuine problem here but, as noted at the time, its definitely not the same problem as the original report (as the shadings do not need converting). It is barely possible, since the file contains nonsense transparency operations, that an older version of the code degenerated to rectangles, but that seems unlikely. However in the absence of a command line, or a version number, and the fact that its not the same problem anyway, I'm going to ignore this one.