Apache OpenOffice (AOO) Bugzilla – Issue 110857
unexpected differences in application char vs basic chr functions
Last modified: 2015-12-18 20:00:43 UTC
note: version is actually OOO300m15 not OOO300m9 if that makes a difference. char and chr functions seem to return different results for ascii characters 128 to 159. What I did: populate column a rows with values 1 - 255 populate column b rows with values char(a1) - char(a255) create a function under OOo BASIC for current spreadsheet Function testchr(acode as Integer) As String testchr = Chr(acode) End Function populate column c rows with values testchr(a1) - testchr(a255) fwiw, this does not seem to be the case with excel - char and chr in excel return the same results
As given in description. AOO410m1(Build:9750) - Rev. 1543812 Rev.1543812 Win 7
The CHAR function in Calc: void ScInterpreter::ScChar() { RTL_LOGFILE_CONTEXT_AUTHOR( aLogger, "sc", "er", "ScInterpreter::ScChar" ); //2do: make it full range unicode? double fVal = GetDouble(); if (fVal < 0.0 || fVal >= 256.0) PushIllegalArgument(); else { String aStr( '0' ); aStr.SetChar( 0, ByteString::ConvertToUnicode( (sal_Char) fVal, gsl_getSystemTextEncoding() ) ); PushString( aStr ); } } The Chr function in Basic: RTLFUNC(Chr) { (void)pBasic; (void)bWrite; bool bChrW = false; implChr( rPar, bChrW ); } void implChr( SbxArray& rPar, bool bChrW ) { if ( rPar.Count() < 2 ) StarBASIC::Error( SbERR_BAD_ARGUMENT ); else { SbxVariableRef pArg = rPar.Get( 1 ); String aStr; if( !bChrW && SbiRuntime::isVBAEnabled() ) { sal_Char c = (sal_Char)pArg->GetByte(); ByteString s( c ); aStr = String( s, gsl_getSystemTextEncoding() ); } else { sal_Unicode aCh = (sal_Unicode)pArg->GetUShort(); aStr = String( aCh ); } rPar.Get(0)->PutString( aStr ); } } So Basic uses the full unicode range, Calc uses a system text enconding. Calc should follow ODFF for Char() which states: --snip-- 6.20.3CHAR Summary: Return character represented by the given numeric value Syntax: CHAR( Number N ) Returns: Text Constraints: N <= 127; Evaluators may evaluate expressions where N >= 1, N <= 255. Semantics: Returns character represented by the given numeric value. Evaluators should return an Error if N > 255. Evaluators should implement CHAR such that CODE(CHAR(N)) returns N for any 1 <= N <= 255. Note 1: Beyond 127, some evaluators return a character from a system-specific code page, while others return the [UNICODE] character. Most evaluators do not allow values greater than 255. Note 2: Where interoperability is a concern, expressions should use the UNICHAR function. 6.20.25 See also CODE 6.20.5, UNICHAR 6.20.25, UNICODE 6.20.26 --snip-- We fail the case where CODE(CHAR(N)) = N for any 1 <= N <= 255, as our CODE(CHAR(N)) returns 0 for N > 127, but it's only a *should*. We are allowed to return a character from a system-specific code page as per Note 1. Also as per Note 2 UNICHAR should be used when interoperability is a concern, and UNICHAR's output matches Basic's Chr(). Resolving NOT_AN_ISSUE.
Actually hold on, let me do some more testing with Excel before I close it.
Yes apparently MS Office 2007's Excel uses unicode for CHAR(), not the system text encoding, and has no UNICHAR(), so we are incompatible with it even though we do comply with the ODFF. What now?
(In reply to damjan from comment #4) > Yes apparently MS Office 2007's Excel uses unicode for CHAR(), not the > system text encoding, and has no UNICHAR(), so we are incompatible with it > even though we do comply with the ODFF. What now? OK, let's step back and look at this more deliberately. Regina may have information about what the ODF folks might be doing here. We should also check LibreOffice to see if there is a change there and what happens for down-level cases.