Current HEAD (rev 11540) does not display (on screen) text and images correctly when used from GSView. Most of the text/ etc is displayed in grayscale instead of colour, colour raster images are displayed in a sort of grayscale but overlayed with a semitransparent red rectangle. Revision 11305 does not exhibit this problem, revision 11306 does. I will attach a sample file, screenshots, and command file to reproduce with GS alone. I don’t have any patch to suggest for this one.
Created attachment 6540 [details] Simple sample file. Obtained by printing a GS Bugzilla search results page. Note that some text is red (the 2nd bug, P2 blocking), various other elements are in colour.
Created attachment 6541 [details] Screenshot from a ‘pure’ revision 11540.
Created attachment 6542 [details] Screenshot from revision 11540 + an unrelated patch. The screenshot is taken by from 11540 to which I applied the patch from bug #691494 comment #3, to separate the issues. The clipped glyphs with yellow right borders (and now I also notice the truncated row backgrounds) in the screenshot from comment #2 come from bug #691494. The lack of colour for text and the red overlays on buttons look as having a different cause.
Created attachment 6543 [details] @commandfile Contains parameters otherwise passed by GSView. Usage: gswin32c "@Bug691494-[grayandred]-commands.txt" -f "Bug691494-[grayandred]-sample.ps"
I apologize, I swapped by mistake the filenames for the 2 screenshots, so I uploaded them swapped. The one from ‘pure’ Ghostscript is attachment #6542 [details], the one from patched GS is attachment #6541 [details].
Created attachment 6547 [details] tiger.eps - gsview and ghostscript command line side by side screenshot of tiger.eps - gsview and ghostscript svn HEAD (r11541) command line, side by side. They are using the same DLL but obviously rather differently, and gsview's display is quite wrong. SaGS: Can you get something like this with tiger.eps or some of the files in the example directory?
RE: comment #6 Indeed, all files in the examples\ show problems, with the exception of ridt91.eps. Colour files show in colour when displayed by GS directly, but grayscale when displayed by GSView. Also in GSView fills are truncated, and there are those colour irisations at the horizontal edges of the truncated fills; this latter problem dissapears after the patch attached to bug #691494 comment #3. I also tried other files containing raster images (looks like none of the GS examples does), and in GSView they appear in grayscale with an overlayed semitransparent red rectangle but OK in GS. Note that by ‘GS directly’ I also mean ‘without setting any special options’. Ridt91.eps looks ok even in GSView, don’t know why it’s an exception. As a side note, displaying annots.pdf with GS alone I get .\base\gsicc_littlecms.c:33: gscms_error(): cmm error : Corrupted memory profile but I think that’s not related to the other problems.
(In reply to comment #7) > As a side note, displaying annots.pdf with GS alone I get > > .\base\gsicc_littlecms.c:33: gscms_error(): cmm error : Corrupted > memory profile I think I filed a bug for exactly this a few weeks ago and it is supposedly fixed. I don't have such error with 11541 - what version of post-icc-merge gs are you using?
(In reply to comment #8) > (In reply to comment #7) > > As a side note, displaying annots.pdf with GS alone I get > > > > .\base\gsicc_littlecms.c:33: gscms_error(): cmm error : Corrupted > > memory profile > > I think I filed a bug for exactly this a few weeks ago and it is supposedly > fixed. I don't have such error with 11541 - what version of post-icc-merge gs > are you using? In bug 691401 when Michael fixed this, he mentioned that it should only appear in debug builds - is that what you have? If you have a release build, in the other bugs you mentioned you have COMPILE_INIT=0 - where are you running gs in relation to the on-disk color profiles? I am wondering about whether adding -dGraphicAlphaBits=1 to GSview's configure would help, as the other bugs you mentioned the problem with text is with dTextAlphaBits . There is a little panel in gsview's configuration where one can add flags to pass to ghostcript.
About ‘cmm error : Corrupted memory profile’ --- Yes, I’m using the debug build. It was rev 11540 with COMPILE_INITS, now I also checked 11541 (latest yet) with COMPILE_INITS. I do get this message with examples\annots.pdf, but not with other examples. however: either annots.pdf is damaged and it needs to be fixed sometime (very minor problem, so far form urgent), or maybe there’s a real bug in extracting colour profile from the PDF in which case hiding the message doesn’t help. About the Text/GraphicsAlphaBits --- I tried now all 9 combinations of Text/GraphicsAlphaBits=1/2/4 with ‘pure’ rev 11541, COMPILE_INITS=1, debug build. - The ‘grayscale instead of colour’ and ‘red overlay over images’ are always present. These are the subject of the current bug. - The ‘clipped text’ appears only when TextAlphaBits > 1, and ‘clipped row backgrounds’ only when GraphicsAlphaBits > 1; both disappear after applying the patch from bug #691494 comment #3. These are the subject of the other bug (bug #691494).
My primary suspect was /DisplayFormat, so I tried the following: (a) /DisplayFormat as set by GSView, -dNODISPLAY: gswin32c -dNODISPLAY -c "<< /DisplayFormat 16#30804 /OutputDevice /display >> setpagedevice" -c "currentpagedevice /DisplayFormat get == flush" -f "Bug691495-[grayandred]-sample.ps" (b) /DisplayFormat with Ghostscript’s default value, -dNODISPLAY: gswin32c -dNODISPLAY -c "<< /DisplayFormat 16#30884 /OutputDevice /display >> setpagedevice" -c "currentpagedevice /DisplayFormat get == flush" -f "Bug691495-[grayandred]-sample.ps" (c) /DisplayFormat as set by GSView, without -dNODISPLAY: gswin32c -c "<< /DisplayFormat 16#30804 /OutputDevice /display >> setpagedevice" -c "currentpagedevice /DisplayFormat get == flush" -f "Bug691495-[grayandred]-sample.ps" - (a) and (b) set the requested /DisplayFormat and show a wrong image. - (c) displays the correct image, and does not respect the /DisplayFormat. Note that both (b) and (c) result in the same /DisplayFormat value, the default one; one is OK but not the other. The difference is that (b) starts with -dNODISPLAY and later selects the output device, while (c) goes on with the default initialization. Maybe in the former case the display device is not initialized correctly.
Created attachment 6603 [details] red.ps Simplest possible test file; a large red rectangle.
The following command: gs\debugbin\gswin32c.exe -f "red.ps" or gs\debugbin\gswin32c.exe -c "<< /DisplayFormat 16#30884 /OutputDevice /display >> setpagedevice" -f "red.ps" displays a large red page, as expected. This command however, does not: gs\debugbin\gswin32c.exe -dNODISPLAY -c "<< /DisplayFormat 16#30884 /OutputDevice /display >> setpagedevice" -f "red.ps" The difference does not appear to be in anything the display device is doing, rather it is to do with the mapping of colors. In the two working cases, we start with a display device already defined. When we come to start drawing the red rectangle, the current color is an ICC one, that "concretises" to rgb. This calls into the display device, and we get the expected output. In the non-working case, when we come to start drawing the red rectangle, the current color is an ICC one, that "concretises" to gray. This means that the drawing operations make the following sequence of function calls: gs_rectfill -> gx_remap_ICC -> gx_remap_concrete_ICC -> gx_remap_concrete_DGray -> cmap_gray_direct -> display_map_rgb_color_rgb This gives us the wrong result (we don't want a greyscale rendition of red, we want red!). In addition I think something else goes wrong as we don't reach the showpage in the failing cases. My working hypothesis (which may be horribly wrong) is that the initial ICC color is set with reference to the pagedevices default space (i.e. if we have a pagedevice that is natively RGB, the ICC color will 'concretise' to RGB). It seems that when the pagedevice is reset we should re-evaluate the color - this doesn't appear to be happening. This will require a lot more digging, and probably some advice from Michael.
> In addition I think something else goes wrong as we don't reach the > showpage in the failing cases. Actually we do reach the showpage, just the side effect of -dNODISPLAY is to set DISPLAYING to false, which gs_init.ps uses to disable the prompt/wait for key on showpage, so this is exactly to be expected. > My working hypothesis (which may be horribly wrong) is that the initial ICC > color is set with reference to the pagedevices default space My working hypothesis was indeed horribly wrong. It's not the ICC colour that's the problem, but the ICC managers stored device profile. When we first call gsicc_init_device_profile, it looks to see if the manager has a device_profile setup. If it doesn't, it calls gsicc_set_device_profile. This function then repeats that check, and if it doesn't have one, sets one up. The problem is that in the -dNODISPLAY case, when these functions are first run, they set the device_profile up based on a greyscale output device. When the display device is subsequently selected, the checks in both the functions mentioned stop the device profile being corrected to be based on RGB. A simple fix of removing the 'if (pgs->icc_manager->device_profile == NULL)' tests from both functions makes it work, but this may be horribly inefficient. Need to discuss with Michael.
Created attachment 6607 [details] A proposed patch currently being tested With this patch, a better check for changes in the device profile is made. Also, in zputdeviceparams a call is made to reset the device profile in case gs_putdeviceparams ended up changing the process color model for the device. Note that other interpreters (PCL), which do a call to gs_putdeviceparams will need to do something similar. The call to gs_putdeviceparams at the bottom of pl_main_universe_select appears to need to be followed by a call to gsicc_init_device_profile(igs, dev). It is not clear to me where to find a pointer to the current graphic state in that part of the PCL code though. Also, note that passing pgs into gs_putdeviceparams to have the call to gsicc_init_device_profile made in gs_putdeviceparams is not really an option because of the device set up with gs_putdeviceparams in clist_setup_render_threads, where there is not a pgs (and hence an icc_manager) available. So we need to do the fix in each of the interpreters.
Fixed with rev11619, which moved the device ICC profile into the device structure. When set params occurs for the device, the profile will now be reset if the process color model changes.