On Sat, 02 Jan 2010, Lorenzo Fiorini wrote:
Hi,
> > In Windows CP-125[02345678], IBM CP-874 and our modified ISO-8859-1B
> > it's at possition 128 so if you use one of the above CPs then:
> > ? CHR( 128 )
> > should show euro sign.
> After many tests with postgresql, mysql, pdf, rtf, xls it seems that
> ITWIN is the best solution also for Linux/OSX.
> Euro sign is shown correctly at 0x80 even in an html page with
> encoding="ISO-8859-1".
Lorenzo, 0x80 is not correct position for euro sign in any ISO CPs.
None of ISO CPs contains characters in range 0x80 - 0x9F. These are
control codes in many hardware devices so such range is excluded.
As usual MS defined unportable CPs using characters in reserved range
so for the rest of world it's a bug. I.e. some terminals may not show
such characters but use them as control codes.
Because this range of characters is not used then in some programs
it's hacked to accept some other characters character. Recently they
begin to convert CHR(0x80) to unicode 0x20AC character as workaround
for buggy programs which use ISO-8850-1 CP with euro sign. ISO-8859-1
does not contain euro sign so any program or text like HTML page which
sets ISO-8859-1 and then try to use euro sign without explicit unicode
value encoding is wrong and has to be fixed. In some software audits
such basic things are checked at the beginning so it's important to
keep correct encoding if you want to expect positive results.
AFAIR in the past you asked me to add such hack for euro sign into
GTXWC so now we have in gtxwc.c this code:
if ( outISO == 0x20ac )
{
buf[0] = (BYTE) 0x80;
n = 1;
}
and as usual dirty hack sooner or later creates new problems.
Above code should be removed and we should implement clean solution
probably using real input context. It needs some additional
modifications but it's necessary also for extended keyboard layouts
in some countries. I do not have time for it now so as temporary
solution I'll replace above code with other hack which will not use
hardcoded euro position and maybe I'll return to this problem in the
future in some spare time and change keyboard code in GTXWC to use
input context.
> In mysql 5.0 latin1 is indeed cp1252 and in oocalc Windows
> 1252/WinLatin1 is the only encoding I found that shows the dbfs
> correctly. Not to mention that it makes easy to share data between
> gtxwc and win/gtwvt apps.
> So I plan to move from:
> REQUEST HB_CODEPAGE_ITISB
> HB_SETCODEPAGE( "ITISB" )
> HB_SETTERMCP( "ITISB", "ITISB", TRUE )
> to
> REQUEST HB_CODEPAGE_ITWIN
> SET( _SET_CODEPAGE, "ITWIN" )
> HB_SETTERMCP( "ITWIN", "ITWIN", TRUE )
> for all my platforms.
> Am I missing anything?
ITISB (ISO-8859-1B) is nothing more then non portable local Harbour CP
anyhow it has euro sign in exactly the same position as in ITWIN
(CP-1250) so above does not change anything for using euro sign.
Of course I'm talking about default Harbour CPs. If you have different
results then it means to you used modified ITISB or you made some mistake
in your tests. It doesn't matter what CP you will use. The only one
important thing is using correct values for different encoding so other
programs can correctly decode the data.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
