[Moved from http://xprint.mozdev.org/show_bug.cgi?id=1379 to Freedesktop.org's bugzilla] -- snip -- [follow-up to http://bugzilla.mozilla.org/show_bug.cgi?id=80562] Xprt's PS DDX requires to use |XInstallColormap();| to use any non-default visual (like the TrueColor visual). The PCL DDX does not require this - I think this is a bug... ------- Additional Comment #1 From Roland Mainz 2004-07-11 20:07 ------- Egbert: Can you take a look at the issue, please ? ------- Additional Comment #2 From Egbert Eich 2004-07-12 04:41 ------- Hm, I'm not an expert on Xprt, but there is no default colormap for non-default visuals, therefore you need to install one first. The behavior may differ between implementations but I don't think the behavior is wrong and one cannot conclude from the behavior of one DDX implementation that another one must act the same way. -- snip --
Egbert Eich wrote: > Hm, I'm not an expert on Xprt, but there is no default colormap for > non-default visuals, therefore you need to install one first. The visual we're talking about is a TrueColor visual... I thought TrueColor visuals do not need a colormap at all (this was at least my experience in the last couple of years :) > The behavior may differ between > implementations but I don't think the behavior is wrong and one cannot > conclude from the behavior of one DDX implementation that another one must act > the same way. I still think something is wrong. AFAIK the colormap should come from the window and not from a private per-screen variable... or am I wrong here ?
Created attachment 467 [details] [review] Patch for 2004-07-12-trunk
Comment on attachment 467 [details] [review] Patch for 2004-07-12-trunk Requesting r= ... The patch works similar to what the PCL DDX does. At least Mozilla prints OK and I'll test the Xaw applications and Qt later...
Comment on attachment 467 [details] [review] Patch for 2004-07-12-trunk Sorry, but I have neither the knowledge of this area of the code, nor the time to review this right now.
Alan Coopersmith wrote: > (From update of attachment 467 [details] [review]) > Sorry, but I have neither the knowledge of this area of the code, nor the time > to review this right now. ;-( I've done more testing and the patch seems to work at least with Mozilla, Qt and Xaw applications... I hope nothing gets regressed with that change...
Created attachment 487 [details] [review] Patch for checkin
Patch checked-in... /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.98; previous revision: 1.97 /cvs/xorg/xc/programs/Xserver/Xprint/ps/Ps.h,v <-- Ps.h new revision: 1.3; previous revision: 1.2 /cvs/xorg/xc/programs/Xserver/Xprint/ps/PsColor.c,v <-- PsColor.c new revision: 1.3; previous revision: 1.2 /cvs/xorg/xc/programs/Xserver/Xprint/ps/PsGC.c,v <-- PsGC.c new revision: 1.3; previous revision: 1.2 ... marking bug as FIXED.
Comment on attachment 487 [details] [review] Patch for checkin nominating for X11R6.8.2 as needed by the Qt library and KDE.
Comment on attachment 487 [details] [review] Patch for checkin Approved for the X11R6.8.x branch in the 2004-11-17 release-wranglers phone call. Please don't commit it yourself, I'll handle that once the CVS service is available again.
Comment on attachment 487 [details] [review] Patch for checkin Clearing approval flag as the patch seems to be already in the X11R6.8.x stable branch.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.