Originally Posted By: Doomstars
I'd do it a bit differently. I know mIRC supports colours from 0 to 99 already; it just repeats every 16 colours.

Since when? Nothing from ^K16 to ^K99 generates any colors for me. For me, ^K16 to ^K99 act like ^O but without also undoing bold/italics/reverse/underline. They all "undo" color, resetting a line back to its default color.

Quote:
I don't see why 20 through 83 can't be used for a 6-bit colour palette, with 16 of them being the original 0 through 15. However, those 64 colours should be locally customizable.

See: EGA Colours

Heaven forfend. Let's please not unearth that relic. wink It's little more than a set of 4 variations of the original CGA/EGA text mode color palette.

If there is going to be an extension of the IRC color code system, it should either be:

* Direct RGB, and to balance excessive color control code lengths against color granularity, it should probably be a 4096 color RGB system using a brand new color ^control code + "000" through "FFF" [+ "," + "000" through FFF"]). This would limit each code's length to 8 characters maximum (4 when background color isn't also given) while otherwise still offering extremely fine-grained color selection (for a text medium, anyway).

Or:

* A carefully designed, non-customizable, 82 color palette compatible with the existing ^K system (by using values 16-98, saving 99 for transparency). I say non-customizable because one of the main complaints people have with ^K00-^K15 is that nobody can ever be sure which colors they will produce in other users' clients. If the IRC color code system is to be extended, the new color range should not be allowed to inherit that problem. To compensate for the inability to customize it, it should simply be carefully designed: so as to be "chromatically unbiased," with every possible primary, secondary, and tertiary color represented, and each one in multiple luminosities. Doing that would actually eliminate most desire to customize, since with such careful palette color selection, people will already be able to find very close matches for whatever hues they actually desire.


Personally, I prefer the second option. And the reasons are the disadvantages of the first option. Direct RGB most definitely will require a new ^control code followed by up to 7 characters, for up to 8 characters total. Unlike the recent addition of ^I for italics, where old clients only see one strange character per use, the sight of ^?XXX,XXX will cause much more offense to those using older clients, especially in cases of multiple invocations (think colorful channel topics). People will take sides, bots will be scripted to auto-/kick, ad nausea. Also, IRC daemons with color code-stripping and color message blocking channel modes will require updates to handle stripping and blocking of the new ^?XXX,XXX format RGB codes.

Comparatively, isn't it true that most (if not all?) existing IRC clients treat ^K16-^K99 the way mIRC does (by treating ^K16-^K99 as "go back to line's default color")? If so, the ^K16-^K98 palette method would not heap plagues of control code gibberish upon users of older clients. (The worst ^K16-^K98 would do is cause older client users to see no color where color should exist. King Legibility, though, would be preserved.) Also, most IRC daemons with color stripping (or color message blocking) channel modes either look only for ^K, or simply parse for and strip "^K##,##". So the ^K16-^K98 palette method would require no updates in most of their cases.

On that note, I put this together. Please note: while I can pass tests like this one with flying colors (pun intended), I do not own a professional, ISF calibrated monitor. As such, the palette color values you see in the image below should be treated as extremely "alpha" -- requiring fine-tuning by someone with both excellent color sensitivity and a big, expensive, accurate display device. smile Nevertheless, even in its "alpha" state, this palette still nicely illustrates the effectiveness of the design goal stated above (offering multiple luminosities of all the primary, secondary, and tertiary colors). Done that way, it's very hard to argue that even more colors could be necessary for a text medium.