80562 - Xprint does not support any other visuals than Xprt's default one...

Status: RESOLVED FIXED

(Core Graveyard :: Printing: Xprint, defect)

Description

[Roland Mainz]

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...

Comment 1

[Masaki Katakai]

Assign to Roland.

Comment 2

[Roland Mainz]

Accepting bug.

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

Comment 3

[Roland Mainz]

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...
;-(

Comment 4

[Roland Mainz]

Retargeting to milestone 0.9.4... ;-(

Comment 5

[Roland Mainz]

Retargeting to 0.9.5 ...

Comment 6

[Roland Mainz]

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 ... ;-(

Comment 7

[Jonadab the Unsightly One (Nathan Eady)]

Too late for 0.9.6, this needs retargeting.

Comment 8

[Roland Mainz]

Attachment: Minor nit...

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

Comment 9

[Roland Mainz]

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

Comment 10

[Masaki Katakai]

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

Comment 11

[Roland Mainz]

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

Comment 12

[Roland Mainz]

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 --

Comment 13

[Roland Mainz]

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) ...

Comment 14

[Roland Mainz]

Attachment: Patch for 2002-02-23-08-trunk, requires patch from bug 127657

Comment 15

[Roland Mainz]

Requesting r=/sr= ...

Comment 16

[Daniel Brooks [:db48x]]

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

r=db48x

Comment 17

[Marc Attinasi]

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

sr=attinasi

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

a=roc+moz

Comment 19

[Roland Mainz]

Fix checked in, marking bug as FIXED.

Comment 20

[Roland Mainz]

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...