Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour
On Sat, 20 Feb 2010, Szak�ts Viktor wrote: Hi, --- (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_REDRGB( 0x85, 0x00, 0x00 ) #define RGB_MAGENTARGB( 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. If you are interesting then Clipper uses original VGA colors with the following values: /* black rgb:00/00/00 */ /* blue rgb:00/00/AA */ /* green rgb:00/AA/00 */ /* cyan rgb:00/AA/AA */ /* red rgb:AA/00/00 */ /* magenta rgb:AA/00/AA */ /* brown rgb:AA/55/00 */ /* light grayrgb:AA/AA/AA */ /* gray rgb:55/55/55 */ /* light bluergb:55/55/FF */ /* light green rgb:55/FF/55 */ /* light cyanrgb:55/FF/FF */ /* light red rgb:FF/55/55 */ /* light magenta rgb:FF/55/FF */ /* yellowrgb:FF/FF/55 */ /* white rgb:FF/FF/FF */ (read from VGA registers by small ASM code I wrote many years ago) I used this colors in GTXWC. Anyhow the intensity of colors strongly depends on type of device so the real printer results can be completely different. Probably I missed the context but I do not understand why Andrzej is mixing RGB palette used in VGA addapters for screen colors and RGB color definitions used in Harobur WIN API functions for printing. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour
Thanks Przemek. I'll fix GTWVT to use the same colors. Brgds, Viktor On 2010 Feb 22, at 20:24, Przemysław Czerpak wrote: On Sat, 20 Feb 2010, Szak�ts Viktor wrote: Hi, --- (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_REDRGB( 0x85, 0x00, 0x00 ) #define RGB_MAGENTARGB( 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. If you are interesting then Clipper uses original VGA colors with the following values: /* black rgb:00/00/00 */ /* blue rgb:00/00/AA */ /* green rgb:00/AA/00 */ /* cyan rgb:00/AA/AA */ /* red rgb:AA/00/00 */ /* magenta rgb:AA/00/AA */ /* brown rgb:AA/55/00 */ /* light grayrgb:AA/AA/AA */ /* gray rgb:55/55/55 */ /* light bluergb:55/55/FF */ /* light green rgb:55/FF/55 */ /* light cyanrgb:55/FF/FF */ /* light red rgb:FF/55/55 */ /* light magenta rgb:FF/55/FF */ /* yellowrgb:FF/FF/55 */ /* white rgb:FF/FF/FF */ (read from VGA registers by small ASM code I wrote many years ago) I used this colors in GTXWC. Anyhow the intensity of colors strongly depends on type of device so the real printer results can be completely different. Probably I missed the context but I do not understand why Andrzej is mixing RGB palette used in VGA addapters for screen colors and RGB color definitions used in Harobur WIN API functions for printing. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour
From: Viktor Szakáts harbour...@syenar.hu Sent: Saturday, February 20, 2010 3:22 AM Subject: Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour Hi Andrzej, From: vszak...@users.sourceforge.net Revision: 13878 [...] * contrib/hbwin/hbwin.ch * Changed to use full (0xFF) color components for RGB presets. 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. 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. 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 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. --- (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_REDRGB( 0x85, 0x00, 0x00 ) #define RGB_MAGENTARGB( 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. 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? 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. [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. -- Regards from The Harbour Project mirror in Poland Andrzej P. Woźniak -- Hosting 2GB za 40 zl brutto http://www.klatka.pl ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour
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_REDRGB( 0x85, 0x00, 0x00 ) #define RGB_MAGENTARGB( 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
Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour
From: vszak...@users.sourceforge.net Sent: Monday, February 15, 2010 12:14 PM Subject: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour Revision: 13878 [...] * contrib/hbwin/hbwin.ch * Changed to use full (0xFF) color components for RGB presets. 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 -- Regards from The Harbour Project mirror in Poland Andrzej P. Woźniak -- Hosting 2GB za 40 zl brutto http://www.klatka.pl ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour
Hi Andrzej, From: vszak...@users.sourceforge.net Sent: Monday, February 15, 2010 12:14 PM Subject: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour Revision: 13878 [...] * contrib/hbwin/hbwin.ch * Changed to use full (0xFF) color components for RGB presets. 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, nor did it determine the actual colors that appeared on screen, so it's by no means a Clipper compatibility issue. 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. WIN_PRN class is meant to (sort of) emulate line printers on GUI printers, so if anything, these colors should mimic color selection of color printers. Maybe this was the original intent, but it's still very difficult to tell, but even in this case I have some doubts that color printers had chosen just these exact color components for these specific colors as a standard: --- (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_REDRGB( 0x85, 0x00, 0x00 ) #define RGB_MAGENTARGB( 0x85, 0x00, 0x85 ) #define RGB_BROWN RGB( 0x85, 0x85, 0x00 ) #define RGB_WHITE RGB( 0xC6, 0xC6, 0xC6 ) --- 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? :) Please also notice these color macros in hbwin.ch are not printing specific ones, but generic color constants, and current colors are the most generic, pure versions of the base colors: --- (current hbwin.ch) /* Color constants for convenience */ #define HB_WIN_RGB_BLACKWIN_RGB( 0x00, 0x00, 0x00 ) #define HB_WIN_RGB_BLUE WIN_RGB( 0x00, 0x00, 0xFF ) #define HB_WIN_RGB_GREENWIN_RGB( 0x00, 0xFF, 0x00 ) #define HB_WIN_RGB_CYAN WIN_RGB( 0x00, 0xFF, 0xFF ) #define HB_WIN_RGB_RED WIN_RGB( 0xFF, 0x00, 0x00 ) #define HB_WIN_RGB_MAGENTA WIN_RGB( 0xFF, 0x00, 0xFF ) #define HB_WIN_RGB_BROWNWIN_RGB( 0xFF, 0xFF, 0x00 ) #define HB_WIN_RGB_WHITEWIN_RGB( 0xFF, 0xFF, 0xFF ) --- Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour
Revision: 13878 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13878view=rev Author: vszakats Date: 2010-02-15 11:14:14 + (Mon, 15 Feb 2010) Log Message: --- 2010-02-15 12:09 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * INSTALL * Changed to use win-make/dos-make in examples. * contrib/hbwin/win_tbmp.prg - Deleted XBPBITMAP class mapped to WIN_BMP. This should be the job of HBXBP. * contrib/xpp/xpp.hbc + contrib/xpp/tests + contrib/xpp/tests/testdll.prg * contrib/xpp/Makefile + contrib/xpp/win_dllx.c * contrib/hbwin/Makefile - contrib/hbwin/win_dllx.c * contrib/hbwin/tests/testdll.prg + Moved Xbase++ compatible DLL functions to xpp lib. * INCOMPATIBLE change. If you use these functions (DLL*()) add xpp lib to your lib list. ; Finally we don't have any HB_COMPAT_* dependent parts in hbwin. * contrib/hbwin/hbwin.ch * Changed to use full (0xFF) color components for RGB presets. * contrib/gtwvg/Makefile * Deleted trailing spaces. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/contrib/gtwvg/Makefile trunk/harbour/contrib/hbwin/Makefile trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/tests/testdll.prg trunk/harbour/contrib/hbwin/win_tbmp.prg trunk/harbour/contrib/xpp/Makefile trunk/harbour/contrib/xpp/xpp.hbc Added Paths: --- trunk/harbour/contrib/xpp/tests/ trunk/harbour/contrib/xpp/tests/testdll.prg trunk/harbour/contrib/xpp/win_dllx.c Removed Paths: - trunk/harbour/contrib/hbwin/win_dllx.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
