Issue 110857

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.