Created attachment 11484 [details]
"bad" output (screenshot from evince as PNG)
As the PDF file is much larger than the PNG file, I'm providing a screenshot of evince showing the PDF.
Firstly there's no point in sending a PNG file, we're going to need to look at the input, the PostScript file you are using. We don't need the PDF and we don't need any screenshots. Secondly PDF doesn't support CIEBased colour spaces so you are going to get colour conversion and probably some colour shifts. Thirdly you need to use a *recent* version of Ghostscript. 8.62 is six years old and uses a totally different colour management system to current versions. If you see a problem with the current Git master or the current released version (9.15) then we'll definitely look into it, when you provide the source file and command line you are using. Since 8.62 predates ICC colour profiles for colour management, there's no point in Michael being assigned to this. Also, if rendering works properly then its not really a general colour issue. Since the report mentions creating a PDF as the problem, I've altered the component appropriately. Also I've reduced the importance to 'normal' there's no way a bug report against a 6 year old version of Ghostscript is a major problem. Changing the version number isn't going to make any difference, we cannot do anything without the input file, and a command line. Created attachment 11487 [details]
output of Adobe Acrobat XI (screenshot as PNG)
In Adobe Acrobat the CIE colors looks different than in evince, but still wrong.
Created attachment 11488 [details]
The sample PDF file as produced by GhostScript
(In reply to Ulrich Windl from comment #6) > Created attachment 11488 [details] > The sample PDF file as produced by GhostScript The *OUTPUT* is not helpful. In order to investigate any problem we require the input file (in your case the PostScript file) and the command line used. Please supply the input file and command line, as already requested twice. If you do not supply the input file and command line I will be forced to close this bug report. Still no example file and command line, despite 3 requests. We cannot investigate problems without a means of reproducing them, so I'm closing this bug report. On comment 2, comment 4, comment 8: For some reason I got no mail notifications on these. I'll provide a sample as soon as I can access it (it's on a system I cannot reach now). However I played a bit more: The problem also happens with the XYZ color model: X display and PNG export look rather correct, while in PDF export XYZ colors look quite better than La*b* colors do. However some medium gray looks quite brownish. Created attachment 11638 [details]
Color Checker example: This is how PDF is displayed
I tried this: Two color checkers with values taken from argyll CMS sample files. The one above uses XYZ colors (and a different measurement), while the lower one uses La*b* and D65 white point. As you can see the colors from the bottom sample look very wrong.
Created attachment 11639 [details] Color Checker example: This is how PNG is displayed This is a PNG produced by Ghostscript (corresponding to attachment 11638 [details]). Here the colors look quite OK. Created attachment 11640 [details]
Another calibration target: This how the PDF looks like
This sample was also created from values taken from the argyll CMS for a reference target (using XYZ). Note the brownish colors in the gray scale at the bottom.
Created attachment 11641 [details] Another calibration target: This how the PNG is displayed This is the PNG produced by Ghostscript for the same source as attachment 11640 [details]. Here the colors look correct. So my summary would be: PNG export looks correct in most cases, while for PDF export XYZ looks rather correct, while La*b* looks completely wrong. I don't knwow whether: 1) multiple color models are allowed for a single page (or file) in PDF 2) while color models are allowed in PDF But I guessed I could have any color model for any part of a PDF. You appear, again, to have provided the output files. We cannot investigate your problem without an *input* file and a command line. In addition you seem to sometimes be producing PNG files, and (possibly) sometimes PDF files. Yet you have opened the bug report against 'PDF Writer' rather than 'colour'. If you think the output is incorrectly coloured in different configurations then it should be a 'colour' bug not a PDF Writer bug. If the problem only exists when producing PDF files, then its a PDF Writer bug. Now, to make it clear, you must provide us (as an attachment, not a URL) with a copy of an input file *and* a command line which will reproduce a problem with *that* input file. Sending copies of the output is useless. Created attachment 11642 [details]
postscript file with a simple graphic in CIELab
Since he discusses CIE and XYZ, try these two simple examples.
Compare the pdf produced by ps2pdf vs the default display or any image outputs.
Created attachment 11643 [details]
Simple postscript in XYZ
The conversion to pdf is *much* better than ~four years ago when my similar bug was closed wontfix. Mucho kudos on that.
But the resulting pdfs render differently on every pdf viewer I've tried.
Gs's x11 display renders the CIE pdf the same as it does the ps, but not the XYZ.
And mu and evince are radically different from gs and from each other on both.
For the CIE, acro's rendering of the pdf matches gs's rendering of the ps.
But for XYZ they are also radically different.
So the colour space embedded in the pdfs when the ps uses xyz *might* not be quite correct. Maybe.
(In reply to James Cloos from comment #15) > Created attachment 11642 [details] > postscript file with a simple graphic in CIELab > > Since he discusses CIE and XYZ, try these two simple examples. > > Compare the pdf produced by ps2pdf vs the default display or any image > outputs. Rendering the PDF produced against the original PostScript, using the same settings, in Ghostscript produces pretty nearly the identical image for me. Certainly well within any margin of error, given that the CIEBased space must be converted to an ICCBased space, and the sample are given by a function (since ths is a shading). (In reply to James Cloos from comment #16) > The conversion to pdf is *much* better than ~four years ago when my similar > bug was closed wontfix. Mucho kudos on that. The PDF file is reasonably close to the original PostScript when both are rendered with Ghostscript. The primary differences are the area approximately left of centre and extending down towards the bottom right corner where the original shows a large area of pastel/whitish colour and the PDF shows quite saturated colour, and an area of comparatively dark blue in the PDF version. Again, given that the samples are generated for a shading, and we *must* convert the CIEBased space to an ICCBased space, I reckon this is pretty good myself. > But the resulting pdfs render differently on every pdf viewer I've tried. That sounds to me more like a reflection of the viewers involved.... > Gs's x11 display renders the CIE pdf the same as it does the ps, but not the > XYZ. Using the Windows display device, the results are not exactly the same, but really quite similar. I'm not in a position to try the X11 device, and I don't trust it anyway. Like I said, I suspect the differences are down to the way the shading generates intermediate colour samples, and how those are then interpolated into the colour spaces involved. > And mu and evince are radically different from gs and from each other on > both. Well, MuPDF doesn't do colour management, I expect its treating the ICCBased space as RGB, because it has 3 components. The MuPDF output is not a million miles away from the Ghostscript output, though its not the same, granted. Its also pretty close to the Acrobat display when using the Adobe RGB colour profile for proofing. > For the CIE, acro's rendering of the pdf matches gs's rendering of the ps. > But for XYZ they are also radically different. Given that this is a shading, I don't see them as radically different (Ialso see the Lab as different to GS when viewed with Acrobat), though I admit freely they are not *precisley* the same, I'm not surprised, because the samples in the shading are function based, and those will map slightly differently to the colours in the ICCBased space. Indeed the rendering applications may well produce different values for the same input, in a shading. This is one good reason not to use a shading dictionary for comparisons like this. Short of sampling all possible colour values and storing a monster lookup table in the ICC profile, there's no perfect solution to that. > So the colour space embedded in the pdfs when the ps uses xyz *might* not be > quite correct. Maybe. I think its a reasonable approximation to the input myself. While I admit that the Lab is a better approximation than the XYZ that's probably a reflection of the sampling/function generation more than anything else. Created attachment 11644 [details]
Test Case (simplified, so doesn't exactly match the previous examples)
I tried to make a smaller test case. Most conversion formulas for the CIE color spaces were taken from the PostScript reference manual.
Created attachment 11645 [details]
PDF created by Adobe Acrobat XI: Colors look rather correct
When converting the PostScript with Adobe's Acrobat IX, the colors in both color models look correct (when viewed with Adobe Acrobat (windows 7) and evince (Linux)). So I guess Ghostscript has a bug. What both, GhostScript and Acrobat seem to have in common is a poor numeric precision when converting color spaces; specifically the grays look brownish.
Created attachment 11646 [details]
Adobe Acrobat Output (first page) saved as PNG
For reference, here is what Adobe Acrobat produces from the PDF it produced from the PostScript: For both color models (XYZ and La*b*) the colors look correct.
(There wasn't any visible progress on this, so I'll pick up comment #14) > You appear, again, to have provided the output files. Those are present meanwhile (comment #19, comment #20, comment #21). > > We cannot investigate your problem without an *input* file and a command > line. In addition you seem to sometimes be producing PNG files, and > (possibly) sometimes PDF files. Yet you have opened the bug report against > 'PDF Writer' rather than 'colour'. As I said (and as you could see looking at the attachments) the PNG output looks rather OK to me, but not the PDF, so I guessed the bug is in PDFwriter (unless I would do something invalid). [...] > Sending copies of the output is useless. While waiting for the input files, you could have inspected the PDF output to see what PDFwriter actually created. (In reply to Ulrich Windl from comment #22) > (There wasn't any visible progress on this, so I'll pick up comment #14) There is no progress. I'm working on something else and won;t have time to look at this again for a while. > > You appear, again, to have provided the output files. > > Those are present meanwhile (comment #19, comment #20, comment #21). Which postdate comment #14, clearly. In my opinion the comment is not unreasonable given that the bug was opened in February, I requested the input file three times and eventually gave up and closed the bug 4 days later. Where it remained until James provided something to look at 3 months later. > [...] > > Sending copies of the output is useless. > > While waiting for the input files, you could have inspected the PDF output > to see what PDFwriter actually created. Yes, I could have done, but that would have got precisely nowhere, since I have no idea what the input is. Be aware that PDF does not include a concept of CIEBased colour spaces, it uses instead the more modern ICCbased colour spaces. So a PNG with some colours, and a PDF with different colours and a different colour space from the original input doesn't give me anything to go on. Even if it did, its practically impossible to debug a problem of this nature without following the code path, which requires an input file. Now that I have a bug report I can investigate, I will do so. However I am now busy on other projects and this will have to wait until those are finished before I get back to it. Should anyone else be reading tihs bug thread, in general we don't require the output files, not files produced by other applications (eg Distiller). What we do need is: A clear and simple explanation of the problem A file which reproduces the problem (ideally a nice simple one but we'll take what we can get). A command line which exhibits the problem. We got the first part in the report, it took near three months to get a specimen file and we still don't have a command line, though I'm assuming that any which involves pdfwrite will demonstrate the problem. The problem was consecutive uses of different CIE colour values in the same space. Now that we have a file to demonstrate the problem its possible to see and fix this. Commit a6d05fcee5521bc410068b16925c36476f207eab resolves the issue for me. Created attachment 13477 [details] Revised test input (PostSCript) (In reply to Ken Sharp from comment #24) > Commit a6d05fcee5521bc410068b16925c36476f207eab resolves the issue for me. Is that commit visible in any release since then? Maybe you could provide the output for the most recent test file to me. I'm still trying to get a better understanding how color conversion works in PostScript... (In reply to Ulrich Windl from comment #25) > Created attachment 13477 [details] > Revised test input (PostSCript) > > (In reply to Ken Sharp from comment #24) > > Commit a6d05fcee5521bc410068b16925c36476f207eab resolves the issue for me. > > Is that commit visible in any release since then? Of course, in every release since that date. So that's 9.18, 9.19, 9.20 and 9.21. > Maybe you could provide > the output for the most recent test file to me. After more than 18 months ? No. Use one of the releases with the fix and you can produce this for yourself. > I'm still trying to get a > better understanding how color conversion works in PostScript... You aren't colour converting 'in PostScript', you are using Ghostscript to convert a colour space in PostScript into a (broadly equivalent) colour space in PDF. We which cannot use the original colour space, because PDF does not permit CIE colour spaces, only ICCBased spaces. If you want to do colour management, then Ghostscript has many features for this, they are documented in ghostpdl/doc/GS9_color_Management.pdf. However, its worth remembering that the pdfwrite device will, in the default configuration, do its best to preserve the input colours in the output. I also wouldn't go near CIE colour spaces for colour management unless you have a very good understanding of colour and PostScript. Trying Ghostscript 9.21 for/on Windows, I found that my test file still shows very different output for the last two pages (comparing interactive window output with the PDF file displayed with Adobe Acrobat). What I don't understand is this: If all colors are presented as CIE XYZ internally before being rendered (I'm referring to figures 4.5 and 4.6 in PostScript Language Reference, third edition), why is it so difficult to map these XYZ colors to PDF colors? (In reply to Ulrich Windl from comment #27) > Trying Ghostscript 9.21 for/on Windows, I found that my test file still > shows very different output for the last two pages (comparing interactive > window output with the PDF file displayed with Adobe Acrobat). I output the test file to PDF in order to get reasonable comparisons with Acrobat (and also because you opened the bug report with the component 'PDF Writer'). For me the two files are very, very similar in appearance when viewed in Acrobat. If you render to the (RGB) display device, then this becomes a colour management question, not pdfwrite. If you think that this rendering is not correct then I would suggest that in that case you open a new bug report with the component as 'colour'. > What I don't understand is this: If all colors are presented as CIE XYZ > internally before being rendered (I'm referring to figures 4.5 and 4.6 in > PostScript Language Reference, third edition), why is it so difficult to map > these XYZ colors to PDF colors? Because PDF **DOES NOT SUPPORT CIE**, in particular it does not support the CIE XYZ space directly. The CIE colours need to be represented in an ICCBased colour space. Clearly we didn't get an ICCBased space from the input (because PostScript cannot use an ICCBased colour space), we got a CIEBased colour space, so we need to sample the original space and produce an ICCBased space which is representative of it. Indeed, as far as I can see, this works well. You can't compare the RGB screen rendering with production of a PDF file, the two are quite different tasks and handled in very different ways. You must decide which of these you consider to be a problem, the production of a PDF file or the rendering to screen. As I've said, the PDF file produced by pdfwrite looks very similar to the PDF file produced by Distiller, when viewed using Acrobat. That's our usual comparison when examining PDF output problems. I also do not see 'very different' output when using the Windows display device between the Acrobat display (using an Adobe RGB profile) of the original PostScript file converted to PDF using Distiller, the original PostScript file converted to PDF using Ghostscript, and the Ghostscript RGB rendering of the original PostScript file, the Distiller-produced PDF file ro the Ghostscript-produced PDF file. There are differences in the shadings, between the PDF files and the PostScript, this is not surprising because the shadings use a function to interpolate the samples in the colour space. If you change the colour space (from CIEBased XYZ into ICCBased) then yes, there will be some differences in the interpolation. Bear in mind that the ICCBased space has been produced by some form of sampling and interpolation already, so you are interpolating inside an already interpolated table. Naturally a single level of interpolation yeilds somewhat different results. I wouldn't say they are massively different however. In short, I can't see what you regard as the problem here. (In reply to Ulrich Windl from comment #27) > What I don't understand is this: If all colors are presented as CIE XYZ > internally before being rendered (I'm referring to figures 4.5 and 4.6 in > PostScript Language Reference, third edition), why is it so difficult to map > these XYZ colors to PDF colors? The only time that the XYZ is rendered to the device is when you run the PostScript program to Ghostscript. Neither the Ghostscript pdfwrite device, nor Acrobat Distiller does any form of rendering when producing a PDF file from this PostScript. Instead the PDF file contains a description of the same vector objects as were present in the PDF file. Because we cannot put a CIEBased colour space in the PDF, we must convert that to an ICCBased space. So shadings, which are procedurally rendered, *will* look slightly different. When the PDF file is rendered, the colour space which is used is the ICCBased space, not the CIEBasedXYZ space. If you set CompatibilityLevel in Ghostscript to 1.1 or 1.2 (so that shadings are not supported) then the resulting PDF file will have a rendered image for the shadings, instead of containing the shading description. This will then look the same as the original PostScript, because we will have rendered the shading using the CIEBasedXYZ space. I no longer have access to a copy of Distiller which will produce a PDF of less than version 1.3 (which is when shadings were introduced) so I can't compare with that. Because Shadings are procedurally generated, they *will* show some differences between being rendered in the original CIEBased space, and the ICCBased space which has to be created for the PDF file from the original CIEBasedXYZ space. If you are attempting colour management of the PostScript to PDF conversion process then using CIEBased colour spaces is not going to work well. You should instead use device colour spaces, and provide DefaultRGB, DefaultCMYK and DefaultGray profiles for inclusion in the PDF file. These are used by PDF consumers (at least those which perform colour management) to map the device colours into ICCBased spaces. You can then supply an OutputProfile to control the production of the output device colours. from ICCBased space Together these constitute a colour managed workflow, as far as I understand it. Trying to do this with CIEBased spaces will not work well. This is a very good reason not to use CIEBased spaces when creating a PDF file of course. Created attachment 13478 [details] Screen Shot comparing PDF, PostScript window, and paper output (In reply to Ken Sharp from comment #29) (...) > The only time that the XYZ is rendered to the device is when you run the > PostScript program to Ghostscript. Neither the Ghostscript pdfwrite device, > nor Acrobat Distiller does any form of rendering when producing a PDF file > from this PostScript. OK, "rendering" was probably the wrong word. But my expectation is something like this: "send test file to postscript printer" == "convert file to PDF, then view or print the PDF" For reference I had sent the test file to a PostScript printer, and the colors match my expectation (so I guess I did not make a mistake in coding). > Instead the PDF file contains a description of the same vector objects as > were present in the PDF file. Because we cannot put a CIEBased colour space > in the PDF, we must convert that to an ICCBased space. So shadings, which > are procedurally rendered, *will* look slightly different. I understand the issues with mapping the full CIE gamut to a specific more restricted gamut, but what I'm talking about are completely different colors. I know providing output is not what is liked here, but to ease talking about the same things, I'm attaching a screen shot that compares what we are talking about: * Viewing a PDF created by Ghostscript * Viewing a PDF created by Adobe Acrobat IX * Viewing the output in Ghostscript's window (on Windows 7) * Viewing the paper output created from a real PostScript printer You should see that Ghostscript's PDF looks quite wrong, Acobat's PDF looks a great deal better, Ghostscript's output window looks quite right, just as the paper output does. What looks most wrong is Ghostscript's PDF. That's what we are talking about. > When the PDF file is rendered, the colour space which is used is the > ICCBased space, not the CIEBasedXYZ space. Yes, the screen can only provide the colors it has (say sRGB or AdobeRGB). But where comes the huge change in hue seen in Ghostscript's PDF from? > If you set CompatibilityLevel in Ghostscript to 1.1 or 1.2 (so that shadings > are not supported) then the resulting PDF file will have a rendered image > for the shadings, instead of containing the shading description. This will > then look the same as the original PostScript, because we will have rendered > the shading using the CIEBasedXYZ space. I must admit that I don't fully understood the shading (shfill) code. So when the instructions to create the shaded fill are put into PDF, these instructions create different colors when the PDF is rendered? Why? > I no longer have access to a copy of Distiller which will produce a PDF of > less than version 1.3 (which is when shadings were introduced) so I can't > compare with that. > > Because Shadings are procedurally generated, they *will* show some > differences between being rendered in the original CIEBased space, and the > ICCBased space which has to be created for the PDF file from the original > CIEBasedXYZ space. I agree that there should be "some" differences, but what I see are completely different colors. > If you are attempting colour management of the PostScript to PDF conversion > process then using CIEBased colour spaces is not going to work well. You > should instead use device colour spaces, and provide DefaultRGB, DefaultCMYK > and DefaultGray profiles for inclusion in the PDF file. These are used by > PDF consumers (at least those which perform colour management) to map the > device colours into ICCBased spaces. You can then supply an OutputProfile to > control the production of the output device colours from ICCBased space. So you are saying if I'd use AdobeRGB as output device color space (for example), the colors would be (more) similar to what I see in Ghostscript's output window? > Together these constitute a colour managed workflow, as far as I understand > it. Trying to do this with CIEBased spaces will not work well. But wouldn't that mean that I'd need different PDFs, depending on the device I want to view (or print) it? I thought the advantage of PDF over other formats is to produce a mostly correct output on any device. > This is a very good reason not to use CIEBased spaces when creating a PDF > file of course. What output color space is used for my test file by default? I thought that is independent from the PostScript code (as long as I don't mess with device-specific parameters). From https://www.pdfa.org/wp-content/until2016_uploads/2011/08/tn0002_color_in_pdfa-1_2008-03-141.pdf I read: "The PDF consumer will use the output intent to convert all device-dependent colors to device-independent colors. Applying standard ICC conversion rules these will in turn be adjust ed to produce the colors on the selected device (e.g. monitor or printer) using the device’s ICC profile.". To me it reads like supporting my view: The PDF contains device independent colors that are converted to device-dependent colors (using a profile) when viewed or printed. Am I confused, or is there still some bug in the PDF produced by Ghostscript? (In reply to Ken Sharp from comment #29) >(...) Because we cannot put a CIEBased colour space in the PDF, we must > convert that to an ICCBased space. (...) https://www.pdfa.org/wp-content/until2016_uploads/2011/08/tn0002_color_in_pdfa-1_2008-03-141.pdf says: "PDF supports various color spaces which can be grouped as follows: Device color spaces (...) CIE-based color spaces (...) Special color spaces: Separation and DeviceN (...)" Which of the two statements is correct? (In reply to Ulrich Windl from comment #31) > (In reply to Ken Sharp from comment #29) > >(...) Because we cannot put a CIEBased colour space in the PDF, we must > > convert that to an ICCBased space. (...) > > https://www.pdfa.org/wp-content/until2016_uploads/2011/08/ > tn0002_color_in_pdfa-1_2008-03-141.pdf says: "PDF supports various color > spaces which can be grouped as follows: Device color spaces (...) CIE-based > color spaces (...) Special color spaces: Separation and DeviceN (...)" > > Which of the two statements is correct? <sigh> that depends. There are CIE spaces defined in PDF; these are Lab, CalGray and CalRGB, as well as ICCBased. None of these match the arbitrary CIEBased spaces available in PostScript. The closest is ICCBased, since it is capable of handling arbitrary CIE colour spaces. However it is not by any means the same as the parameteric CIE colour spaces in PostScript. So you cannot take an arbitrary CIEBased space in PostScript and convert it into a 'CIE-based' space in PDF, you can only convert it into an ICCBased space. While that it 'CIE-based' (ie it uses the definitions from the CIE) its not the same as CIEBased. SO yes, you can have a 'CIE-based' space, no you can't have a CIEBased space. (In reply to Ulrich Windl from comment #30) > OK, "rendering" was probably the wrong word. But my expectation is something > like this: "send test file to postscript printer" == "convert file to PDF, > then view or print the PDF" > For reference I had sent the test file to a PostScript printer, and the > colors match my expectation (so I guess I did not make a mistake in coding). And as far as possible, that's what you get. However, where the capabilities of the two graphics imaging systems do not match, there must be some compromises. > I understand the issues with mapping the full CIE gamut to a specific more > restricted gamut, but what I'm talking about are completely different colors. > I know providing output is not what is liked here, No, that's not the case. I'm happy to have a screenshot, or a PDF file, where it helps clarify the matter. However the primary attachment should always be the input. > You should see that Ghostscript's PDF looks quite wrong, It also looks nothing like the result I get. As I said, the Ghostscript output for me is broadly the same as the Acrobat display. > > When the PDF file is rendered, the colour space which is used is the > > ICCBased space, not the CIEBasedXYZ space. > > Yes, the screen can only provide the colors it has (say sRGB or AdobeRGB). > But where comes the huge change in hue seen in Ghostscript's PDF from? For me, it does not exist. > I must admit that I don't fully understood the shading (shfill) code. So > when the instructions to create the shaded fill are put into PDF, these > instructions create different colors when the PDF is rendered? Why? Because you are using a different colour space. If we sample some points in the colour cube and use those to map the conversion, then any non-linearity in the colour space will result in a different result than would have been the case if you had used the original. > I agree that there should be "some" differences, but what I see are > completely different colors. Which I don't see. Of course, you still have not provided an example command line, so possibly there is some reason. It doesn't happen for me. > So you are saying if I'd use AdobeRGB as output device color space (for > example), the colors would be (more) similar to what I see in Ghostscript's > output window? No. I'm saying if you use device colours instead of CIEBased colours, supply Default* colour profiles to map from device space to CIE space, then you should get approximately similar results from both PostScript and PDF, assuming that your PDF consumer applies colour management (not all do). Adding an OutputProfile further characterises the intended output colour space, which allows a proofing device to match the intended colours more accurately. > But wouldn't that mean that I'd need different PDFs, depending on the device > I want to view (or print) it? If you want to add an OutputProfile, yes. However, simply supplying teh Default* profiles, and using device space would get the answer correct pretty much all the time, since the PDF consumer can supply its own CIE->device space mapping. Assuming again that the PDF consumer is capable of colour management. > I thought the advantage of PDF over other > formats is to produce a mostly correct output on any device. And indeed it does. I think you'll find that all the PDF files you've produced will render pretty much the same on any device. Your problem appears to be that they don't render the same as the PostScript, which is caused by having to convert the exotic colour space you are using. > Am I confused, or is there still some bug in the PDF produced by Ghostscript? I don't see a bug. On the other hand, I don't get the output you do either. Perhaps its time for you to share the command line you are using. Created attachment 13479 [details]
Output of Ghostscript 9.21 from _test.ps
(In reply to Ken Sharp from comment #33) [...] > (...) you still have not provided an example command > line, so possibly there is some reason. It doesn't happen for me. The command used was as simple as can be: "ps2pdf <DOSish input path>\_test.ps <DOSish output path>\_test_gs.pdf" [...] Created attachment 13480 [details] PDF produced with Ghostscript 9.21 on Wndows from attachment #13477 [details] Attachment # 13478 [details] looks OK for me, too, but my PDF (this attachmant) does not. The only obvious difference I noticed was that my Ghostscript seems to default to DIN A4 paper size. (In reply to Ulrich Windl from comment #35) > (In reply to Ken Sharp from comment #33) > [...] > > (...) you still have not provided an example command > > line, so possibly there is some reason. It doesn't happen for me. > > The command used was as simple as can be: "ps2pdf <DOSish input > path>\_test.ps <DOSish output path>\_test_gs.pdf" > [...] Well, rather than use a script I drive Ghostscript directly. My earlier attachment was produced by: gswin32c -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=out.pdf -dAutoRotatePages=false -sPAPERSIZE=A4 _test.ps The additional controls are to match the Acrobat output for size and orientation of the pages. For me that produces a PDF file which is nearly identical with the result of Acrobat Distiller X, when viewed in Acrobat X Pro. Clearly I've used the 32-bit Windows version of Ghostscript, I have no idea what you've used though. Tried the same test with gswin64c in case this is somehow a 64-bit problem, results are identical with the 32-bit test. I cannot reproduce your output. (In reply to Ken Sharp from comment #37) [...] > Well, rather than use a script I drive Ghostscript directly. My earlier > attachment was produced by: > > gswin32c -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=out.pdf > -dAutoRotatePages=false -sPAPERSIZE=A4 _test.ps Running the command with s/win32/win64/ also produced a PDF file like yours (a "correct" one). So my guess is that one of the commands involved in "ps2pdf" does something unexpected. (In reply to Ulrich Windl from comment #39) > (In reply to Ken Sharp from comment #37) > [...] > > Well, rather than use a script I drive Ghostscript directly. My earlier > > attachment was produced by: > > > > gswin32c -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=out.pdf > > -dAutoRotatePages=false -sPAPERSIZE=A4 _test.ps > > Running the command with s/win32/win64/ also produced a PDF file like yours > (a "correct" one). So my guess is that one of the commands involved in > "ps2pdf" does something unexpected. Your output is created as a PDF 1.4, and contains a CIE XYZ profile, mine is marked as PDF 1.4 and uses an Lab profile. Versions of PDF prior to 1.5 could not use version 2 ICC profiles, and so your output uses a version 1 ICC profile. So the simple answer is, don't use the script. (In reply to Ken Sharp from comment #40) > Your output is created as a PDF 1.4, and contains a CIE XYZ profile, mine is > marked as PDF 1.4 That should have read 1.5 of course. (In reply to Ken Sharp from comment #40 and comment #41) [...] > Your output is created as a PDF 1.4, and contains a CIE XYZ profile, mine is > marked as PDF 1.4 and uses an Lab profile. Versions of PDF prior to 1.5 > could not use version 2 ICC profiles, and so your output uses a version 1 > ICC profile. Wouldn't the user benefit from some warning being emitted? [...] > So the simple answer is, don't use the script. [...] > That should have read 1.5 of course. As the chain ends with ps2pdf14, someone might either write a ps2pdf15, or (preferrably) update ps2pdf (Considering the number of years Acrobat 6 is obsolete, it should be OK). From the man page (ps2pdf): ps2pdf per se currently produces PDF 1.4 output. However, this may change in the future. If you care about the compatibility level of the output, use ps2pdf12, ps2pdf13 or ps2pdf14, or use the -dCompatibility=1.x switch in the command line. (In reply to Ulrich Windl from comment #42) > Wouldn't the user benefit from some warning being emitted? My inclination is to scrap the script(s), frankly. They've always been a pain. > From the man page (ps2pdf): We don't produce or maintain man pages for Ghostscript. I'm still reading through the recent notes on this, but I tried converting his _test.ps to pdf with 9.20 and gs -sDEVICE=x11alpha (and the other x11 devices, too, including display) renders the penultimate page of his ps and the resulting pdf quite differently. The ps starts with green at 0,0 but the pdf with red. And the pdf also gets a large red spot at the upper right, too. And the final page also gets a bit of red added near 0,0 which is not there when viewing the ps. The pdf does correctly use a type 7 shading with a pattern/icc colourspace, but the colourspace clearly does not match the ps's /CS_ABC_XYZ_D65 space. It looks like the sampling has some issues near the edge cases. Using Ken's command line worked better on linux, too. As does using ps2pdfwr instead of ps2pdf. ps2pdfwr ends up calling: exec gs -P- -dSAFER -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr -sOutputFile=_wr_out.pdf -P- -dSAFER -c .setpdfwrite -f _test.ps and ps2pdf ends up calling ps2pdfwr with ps2pdfwr -dCompatibilityLevel=1.4 which leads to: exec gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr -sOutputFile=_14_out.pdf -P- -dSAFER -dCompatibilityLevel=1.4 -c .setpdfwrite -f _test.ps I'd say that ps2pdf should default to ps2pdfwr rather than to ps2psd14. (In reply to James Cloos from comment #45) > I'd say that ps2pdf should default to ps2pdfwr rather than to ps2psd14. Time went on, I'm using "GPL Ghostscript 9.26 (2018-11-20)" now, but the bug is still present: When I run "gs file.ps", the colors look OK in the GhostScript window. When I run "ps2pdf file.ps", the resulting pdf has wrong colors. When I run "gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=file.pdf -dAutoRotatePages=false -sPAPERSIZE=A4 file.ps", the resulting PDF has correct colors. When I run "ps2pdfwr file.ps", the resulting pdf has correct colors." In the case where the output is not correct, isn't it possible to output some kind of warning at least? BTW: the bug is marked "resolved/fixed"; which version has the fix, and what is the fix? With ghostscript 9.52, I noticed that colors look wrong for any PDF version lower than 1.7. Unfortunately when using pdflatex it complains when using a PDF version newer than 1.4. For reference the command used was: gs -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOOUTERSAVE \ -dAutoRotatePages=/None \ -dPDFSETTINGS=/prepress \ -sDEVICE=pdfwrite \ -sOutputFile="$OF" \ -sPAPERSIZE=a4 \ -dNOSUBSTDEVICECOLORS -dCompatibilityLevel=1.7 \ "$IF" (and obviously $OF is the output file, while $IF is the input file) |
Created attachment 11483 [details] Annotated "good" output (PNG) I started playing with PostScript Level 2 color models, creating a test document that mixes device colors and CIE colors (L*a*b*). When displaying the test file (X11) the colors meet expectation, also when using PNG or JPEG output. If I convert the file to PDF, all the CIE colors look very wrong. My test file uses device gray levels, device RGB, device CMYK, CIE Lab gray ramp, CIE Lab colors of equal luminance, and CIE colors of equal luminance and saturation.