Current Xprint module code does not support any other visual than the default one - it seems that the code in nsXPrintContext::SetupWindow() simply ignores what xlibrgb returns - it simply uses the screen's default visual. BAD. Additionally the code in xlibrgb ignores the given depth and chooses the depth of the root window. BAD. It may be usefull to make it possible to choose the default visual depth by an ENV var...

Assign to Roland.

Accepting bug. bug 77210 fixed the issue that "nsXPrintContext::SetupWindow() simply ignores what xlibrgb returns - it simply uses the screen's default visual.".

In theory it should work now - but I still have problem with xlibrgb vs. 24bit visual - images are correct but text is reverse b/w - and I do not know why... ;-(

Retargeting to milestone 0.9.4... ;-(

Retargeting to 0.9.5 ...

Technically we support now the PS DDX's 24bit visual, but the resulting output looks weired (http://www.mozilla.org/ prints white text on black background)... xx@@!!!... ;-( Retargeting to 0.9.6 ... I have look at the server code ... ;-(

Too late for 0.9.6, this needs retargeting.

Minor patch, does not fix anything... just a reminder for me...

katakai: Is there any bug in Sun's bug database about any visual issues in Xprt's PostScript DDX ?

I can not find such bug in internal database. Roland, do you have a time to create very simple example to reproduce the problem?

I'll try to hack a minimum testcase...

This looks like a Xprt bug. See PsColor.c: When I disable the check for the TrueColor visual (|cMap->pVisual->class==TrueColor|), e.g. make the expression always true (|1|) the problem gets fixed (when the Zilla uses a TrueColor visual - which can be enabled by setting |% export MOZILLA_XPRINT_EXPERIMENTAL_USE_24BIT_VISUAL=1| before starting it). -- snip -- int PsGetPixelColor(ColormapPtr cMap, int pixval) { int r, g, b; if( 1/*cMap->pVisual->class==TrueColor*/ ) return(pixval); if( pixval<0 || pixval>255 ) return(0); r = cMap->red[pixval].co.local.red>>8; g = cMap->red[pixval].co.local.green>>8; b = cMap->red[pixval].co.local.blue>>8; return((r<<16)|(g<<8)|b); } -- snip --

More data for the log: I pass a type-4(=TrueColor) colormap on the client side (Mozilla) ... -- snip -- XSetWindowColormap(): mPDisplay=844920, mDrawable=400005, mVisual->class=4, cmap=400004 1[3d770]: nsXPrintContext::SetupWindow: mDepth=24, mScreenNumber=0, colormap=400004, mDrawable=400005 -- snip -- ... but server side sees a type-3(=Pseudocolor) colormap... ;-( -- snip -- PsGetPixelColor: 8d65b0(=truecolor 0) visual_class=3 0 --> ffffff PsGetPixelColor: 8d65b0(=truecolor 0) visual_class=3 0 --> ffffff PsGetPixelColor: 8d65b0(=truecolor 0) visual_class=3 ee --> 0 PsGetPixelColor: 8d65b0(=truecolor 0) visual_class=3 ee --> 0 -- snip -- But somehow a XInstallColormap() fixes this. weired. The question is: Why ? Why does Xprt require a |XInstallColormap()| when Xsun works without it (the same xlibrgb code is used for the Xlib toolkit, too) ...

Requesting r=/sr= ...

Comment on attachment 71711 [details] [diff] [review] Patch for 2002-02-23-08-trunk, requires patch from bug 127657 r=db48x

Comment on attachment 71711 [details] [diff] [review] Patch for 2002-02-23-08-trunk, requires patch from bug 127657 sr=attinasi

Comment on attachment 71711 [details] [diff] [review] Patch for 2002-02-23-08-trunk, requires patch from bug 127657 a=roc+moz

Fix checked in, marking bug as FIXED.

Filed http://mozdev.org/bugs/show_bug.cgi?id=1379 ("Cannot use PS DDX's TrueColor visual without calling |XInstallColormap();|") to fix the issue on the Xprt server side...