Hi Andrzej, >>> Viktor, this change is incompatible with Clipper. Previous colours >>> were too dark, but 0xFF should stand for BRIGHT colours. Clipper uses >>> RGBI palette, see here: >>> * 4-bit RGBI palettes for explanation: >>> http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#4-bit_RGBI >>> * EGA colour palette for hex values in implementation: >>> http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter#The_EGA_color_palette >> Clipper had no graphical printing, nor any special color >> printing support for that matter, > > RGBI palette is NOT for printing. I did NOT mention about printing at all.
That's right. It was originally added for printing in context of the hbwin code though. >> nor did it determine the >> actual colors that appeared on screen, so it's by no means >> a Clipper compatibility issue. > > Clipper did NOT define any *own* palette, it just used CGA palette available > in DOS. The palette is used as CGA compatibility palette in EGA/VGA/Windows > till now. Yes. >> If you mean to mimic MS-DOS (or rather VGA/EGA) screen colors >> in Windows printing, I can't see strong reason why this would >> be desired. > > I am not DTP professional, but I know at least two facts: > * You cannot mix RGB and CMYK colour models. RGB is for screen, CMYK is for > printing. All RGB_* #defines are in RGB colour model, so they are not to be > used for printing. See: http://en.wikipedia.org/wiki/RGB_color_model > * There is no simple colour conversion from RGB to CMYK. See: > http://en.wikipedia.org/wiki/CMYK_color_model#Conversion Nevertheless when you print using GDI on Windows, and there you can specify your colors in RGB. Maybe there is alternative way, I don't know, but our current codebase doesn't support it. > As you already know, Clipper did NOT define any print colours and did NOT > use any known printing colour palette. We can use system colour management > (see <http://en.wikipedia.org/wiki/Color_management>) or define our own > colour conversion scheme, but the palette should contain all 16 colours, > normal and BRIGHT. I'm not sure I see your point. These colors are not meant to mimic original EGA/VGA colors. They are just presets for some RGB colors. They have nothing to do with SETCOLOR() functionality. >> --- (from old hbwin.ch) >> #define RGB_BLACK RGB( 0x00, 0x00, 0x00 ) >> #define RGB_BLUE RGB( 0x00, 0x00, 0x85 ) >> #define RGB_GREEN RGB( 0x00, 0x85, 0x00 ) >> #define RGB_CYAN RGB( 0x00, 0x85, 0x85 ) >> #define RGB_RED RGB( 0x85, 0x00, 0x00 ) >> #define RGB_MAGENTA RGB( 0x85, 0x00, 0x85 ) >> #define RGB_BROWN RGB( 0x85, 0x85, 0x00 ) >> #define RGB_WHITE RGB( 0xC6, 0xC6, 0xC6 ) >> --- > > Once again, the above colours are in RGB colour model. They are defined for > display, not for printing. That is not full Clipper colour palette, only > non-BRIGHT part, and brown defined here is not brown on screen. It was not the goal to be full Clipper palette. One may of course create Clipper-alike colors by using different values, but I can't see any use of that in hbwin.ch, neither does it seem like this was intent of original developers using above values. >> F.e. why isn't "white" 0x85/0x85/0x85 to be consistent >> with other colors, or even more, why isn't it pure white: >> 0xFF/0xFF/0xFF, instead of being grey? :) > > I DID write and you DID quote: "Previous colours were too dark", that's > why they are inconsistent. > I DID also write "0xFF should stand for BRIGHT colours", that's why > white is really light grey. And I know that real white may be darker > then the displayed one[1]. > I linked also the explanation, why brown setting should be inconsistent, > did you read it? Well, if your point is that '0xFF/0xFF/0x00' color is wrongly named BROWN, when it should be YELLOW, I see it now. But it's much easier if you say so, or, it's possible I'm still missing your point. I'll commit a fix for the name of that one color. > I don't know why someone used such RGB values for the old colours – maybe > he/she picked them from his/her own display or corrected them as CGA colours > were too bright in his/her opinion. Still they are colours defined in RGB > colour model, that is – for display, not for printing. My best guess is that they were picked randomly, or by personal choice. > [1] A good example for troubles with colour conversion for "red" and "white" > you can see here: > http://en.wikipedia.org/wiki/Flag_of_Poland#Design > http://en.wikipedia.org/wiki/File:Flag_of_Poland.svg > http://commons.wikimedia.org/wiki/File:Flag_of_Poland_(normative).svg > Maybe on your screen you cannot see differences between the flag and the > background colour in any places, but they are. Use some colour picker to > check RGB codes or use some good old CRT monitor. I can see it and it's interesting article (I like flags), just can't see your exact point, sorry. In hbwin.ch these are just a few predefined constants to save some typing, for those users who need these basic RGB color when creating GDI object on screen or printing. My original question was if there was any particular reason to chose those specific RGB values. Still unexplained, so I'm leaving them in their pure forms. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
