Yes, Exactly like this!
But also for HEX values - for two reasons.
1) Hex values are more common for Web Designers to talk about.
You, are quite un-likely to get RGB values from a WEB design house.
2) The HEX values appear in the HTML - not RGB.
Better point of reference for WYSIWYG reasons.
Since, you have to make special classes / methods to deal with HEX values
you might as well make parallel methods for RGB colors. That way the
functionality is complete and consistant - even if you just wrapper the
String convertColor(Color) call in the RGB methods.
Noel W. Clarke
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Claude Duguay
Sent: Monday, August 14, 2000 6:39 PM
To: ECS
Subject: RE: Contributed Code Offer
You mean something like this?
public static Color getSafeColor(Color color)
{
int r = (int)Math.round((double)color.getRed() / 51.0) * 51;
int g = (int)Math.round((double)color.getGreen() / 51.0) * 51;
int b = (int)Math.round((double)color.getBlue() / 51.0) * 51;
return new Color(r, g, b);
}
This'll clip Color values to multiples of 51, rounding where appropriate.
Using String convertColor(Color); can do the rest.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Clarke, Noel
Sent: Monday, August 14, 2000 3:03 PM
To: ECS
Subject: RE: Contributed Code Offer
Claude, Have you considered creating a class which impliments "safe" color
palette. The methods on this class would take a colours as a RGB or HEX
values and return the "Nearest Safe" colour. These safe colours would be
implimented using the colour-cube model to prevent dithering...
Something like
String safeHEXColor getSafeColor(string HexColor)
String safeRGBColor getSafeColor(string RGBColor)
The logic to impliment a safe color pallete would be something like this...
1) Split the three values
2) Take each and make it safe
Round to the nearest safe values
3) combine the safe values
4) return the safe colour as HEX or RGB.
safe RGB values are 0,51,102,153,204,255
safe HEX values are 00,33,66,99,CC,FF
If you have any questions please feel free to contact me.
Yours,
Mr. Noel W. Clarke
Manager of Product Marketing mailto:[EMAIL PROTECTED]
B2B Division
SilverStream Software Inc. http://www.silverstream.com
phone: +1 978.262.3490 #2 Federal Street
fax: +1 978.262.3499 Billerica, MA USA
01821-3559
-----------------------------------------------------------
Certified SilverStream Developer - certification ID: CSD34
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Claude Duguay
Sent: Monday, August 14, 2000 5:27 PM
To: ECS
Subject: Contributed Code Offer
This is a follow to my offer to contribute some code to the ECS project. The
following notes apply to code changes on my hard drive, which can be use to
patch changes if they make sense to you. I had a chance to work on this for
a few hours over the weekend.
1) I developed a WebColor class which converts HtmlColor constants to Color
instances and supports the convertColor method to insure a safe translation
of Color objects into #-prefixed HTML color strings. I noted that the
getColor method in HtmlColor is never used, so I left it out of the WebColor
class.
2) I edited BaseFont, Font, TD, Table, Body, TH, TR to add new methods and
constructors that support the use of Color in setColor and setBgColor. None
of the existing methods or contructor variants that use HtmlColor were
removed. In theory they should probably be marked as deprecated.
3) I removed all but the 'process' method in the Filter interface. This may
be controversial but my observation was that this is the only method used in
any of the other ECS classes. Interfaces should be (as Einstein once said)
as simple as possible, but no simpler. They represent a minimal contract
between the classes that play a role and those that use them. By implication
all the other methods have to be supported but they have to do with the
implementation choice rather than the usage, so I'm assuming that simpler is
better.
4) This distillation down to the process method in a Filter made is easy to
implement two key classes, built on the Match interface (and implementations
from an article I mentioned when I first contacted the group). I placed
these classes in the package org.apache.ecs.filter.match. The concrete
implementations include RegularExpression, Wildcard, Soundex and Alike.
5) The first Filter implementation I wrote is called MatchFilter. It expects
an instance of the Match interface, a string defining token delimiters for
the StringTokenizer used within, and an Object which will replace the
maching token using its toString method. Matching everything is easy if you
define no delimiters (meaning that the string as a whole matches or not - if
delimiters are used, the individual tokens are tested and replaced when
matched). Since the user has control of the token delimiters, they can do
pretty much anything they want this way, providing maximum flexibility and
power for the user, without undue complexity.
6) The other Filter implementation is called MultiFilter and supports the
Filter interface and the inclusion of an arbitrary set of Filter instances.
Each will be tested when the process method executes in the order in which
they were added (using an addFilter method). A removeFilter method is also
provided. Note that this implementation adheres to the model I think you
were after but uncouples the ability to support multiple filters together
from the filter interface. I think you'll find this approach more flexible
and easier to use.
I made the assumption that you were shooting for maximum compatibility.
Though I typically use ArrayList instead of Vector and HashMap instead of
the Hashtable class in most of the current programs I write, I used Vector
in the MultiFilter implementation for this reason. If you are only concerned
with Java 1.2-compatibility and don't care about Java 1.1, the Collection
classes are usually faster (unsynchronized).
Of course, I haven't sent the code yet. I'd like to hear comments on these
changes first and I need to test the functionality, which I haven't done
thoroughly enough to make the code ready for check-in yet. Not having
contributed to an open source project before, I'd like to know that any
suggested improvements are in keeping with the overall vision of the
contributing team. I look forward to hearing from everyone. Sorry if I'm a
little too verbose.
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
