JDK-6203299 : RFE: Ability to specify alternate Color for printing.
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2004-12-02
  • Updated: 2010-05-07
  • Resolved: 2005-03-31
Related Reports
Relates :  
JDK-6201884 - JTable printed text is dithered when using Ocean theme
Description
Some colors that look beautiful on screen may be poorly dithered when printed to a printer. Likewise, some Paints that make sense for the screen should be modified or left out entirely when printing. As a result, objects and components (Swing for example) that were designed mainly for onscreen use may have colors or paints that look poor when printed. As an example of this, see Swing bug 6201884.

It would be nice if Java 2D offered a facility to help solve this problem. Perhaps something that allowed both Swing and external developers to design their Components and/or painting code with the concept of alternate printing colors/paints.

Considering only the Color example for a moment, the idea I find most interesting is one of supplying a new class/interface, PrintColor, that wraps an additional color to use for printing. This PrintColor could then be used in place of Color, and Java 2D's PrintGraphics could detect such an interface and swap out the color. In this manner, a single object could be used for both screen and printing, and the right color value to use would be determined by the context in which it is being used.
Comments
EVALUATION Color is the most important example of where this might be interesting. Other examples include Paint and setComposite and perhaps setStroke. The generalisation of this is to provide an alternative which is more appropriate for printing. The printing implementation would always look for the print color etc. If none were provided it would return the existing color. For this to be useful applications would have to be coded to be use these new APIs. Internal JDK code (such as Swing themes) we have control over, but adoption by external developers is less clear. However it does provide a simple way to customise any colour for printing. For example a background colour may be desirable on screen, but not on printing. Black text may be preferred when printing for better legibility, particularly on B&W printers. The surprise factor is one downside. If a printed UI isn't the same colour as on-screen, someone may be surprised and not understand why, as they had expected an accurate rendition. Since this is under developer control, we would have to expect that this is however what is wanted by the program. Currently the printing implementation uses a slower printing path when printing using translucent colours. A developer could take advantage of such an API to set an opquae colour for printing, and get better, faster printing - although they would need to ensure that this still yielded correct output. ie if the opaque colour meant some important content were overpainted that would not be appropriate. For Color, a getPrintColor() method would be needed but should it be a on subclass, or on a interface implemented by a subclass, or just a new getter on Color? How should the print color be specified? On the constructor, or via a setter? Currently Color has no setters, but its not strictly immutable, since a subclasser could override all methods and provide a way to mutate what they return. The contructor mechanism is more obviously intrusive since all 7 existing constructors may need to be duplicated although its possible to provide fewer by for example adding Color(r,g,b,a,Color) but not Color(r,g,b,Color) so the client has to provide the 255 alpha value rather than defaulting it. ie probably 4 new constructors. We would also need to respecify (somwhere) that implementations of PrinterGraphics should use the print color. Whilst the general notion of an alternate colour etc is easy to see, its less easy to see how to unify the API for this across Color, Paint, Composite as is appropriate. ###@###.### 2004-12-02 19:44:49 GMT After some thought and discussion within 2D, this API isn't appropriate. The Graphics2D isn't the place to handle this. The caller knows the context and should handle it. ###@###.### 2005-03-31 16:54:56 GMT
02-12-2004