janssen@parc.xerox.com (Bill Janssen) (04/17/91)
(Sparc-2, SunOS 4.1.1, patchlevel 9 of ATK compiled under SunOS 4.0.3c) Color behavior on monochrome screens seems broken. Looking at the code (atk/basics/x/xgraphic.c): There seem to be two sorts of color operations: "filling", as in view_FillRect(), and "drawing", as in view_DrawString(), or view_DrawRect*(). Every filling operation takes a tile, while every drawing operation uses the foreground color of the view. If one attempts a drawing operation with a color on a monochrome screen, the color is mapped to a monochrome dither pattern (there seem to be 16 (17?) of these). If one attempts a filling operation with a color on a monochrome screen, the color is thresholded to either black or white, at a very high luminance level (about 0.93), so that any fill color will appear black, unless it is very close to white. (Note that view_EraseRect*() is really a filling operation, as it uses the default view_WhitePattern() of the view for drawing.) I feel that the filling operations should be mapped to a dither pattern just as the drawing operations are. Any justification for not doing so? I further feel that the user should be able to control, on a per-graphic basis, whether thresholding or dithering should be used to represent colors on a monochrome screen -- I find uses for both. Furthermore, when thresholding is used, it should be performed at a reasonable level (0.5), possibly user-specifiable. Another problem is that xgraphic_ApproximateColor() doesn't use XParseColor(), as SetFGColor() and SetBGColor() do, so that filling operations cannot use the "#RRGGBB" convention for X color names, while drawing operations can. I feel that xgraphic_ApproximateColor() should be changed to use XParseColor() in the same way that SetFGColor() does.. Bill
janssen@parc.xerox.com (Bill Janssen) (04/17/91)
Note that if one invokes a "filling" operation with a NULL Tile argument, the foreground color of the view is used, and dithering proceeds as with "drawing" operations. Bill