Problem while formatting numbers with locale fr_BE, output is incorrect in AW 23.7.0

Hi, we have this problem:

I’m using French/Belgium locale for a client & while I tried to upgrade from Aspose Words 21.5.0 to Aspose Words 23.7.0, he bumped into a problem for currency formatting.

Given this number “12345678.06”, while using the fr_BE locale and a number format switch like this # “#.##0,00” the output differs between the two versions.

  • Works well in AW 21.5.0, output is: $12.345.678,06

  • Output is incorrect in AW 23.7.0, output is: $1.234.567.806,00 (it’s like it considers the dot as being thousands separator from the input value)

I’ve also tested this in AW 23.11.0 - still there’s an incorrect behavior, similar to AW 23.7.0

My question is, why is there a difference in behavior in how values are processed? Can you please help?

I’ve also documented a couple of other issues related to number formatting that I’m seeing while using the separator for thousands. (They can be seen & are documented in detail in the output PDFs)

e.g.

  • locale: fr_BE
  • Formatting like this # “# ##0,00”, using space separator for thousands – doesn’t work, only adds the separator to the first thousands group, why? Output: $12345 678,06

  • Format # “#.##0,00”, when dot is used as a separator for thousands, works ok and adds the separator for all thousands groups. Output: $12.345.678,06
    groups.

I’ve attached a small demo code that shows the difference in behavior.
temp.zip (121.0 KB)

1 Like

@oborza
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): WORDSNET-26371

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

1 Like

Hi @alexey.noskov ,

Thanks a lot for your response. I’m looking forward to see this issue being resolved. I’ll track this for a resolution in future releases.
Hoping it will be addressed soon.

@oborza We will be sure to keep you updated and let you know once it is resolved or we have more information for you.

The issues you have found earlier (filed as WORDSNET-26371) have been fixed in this Aspose.Words for Java 24.2 update.

Hi, how was the issue resolved? The initial problem that I’ve initially described is still there, and the number in not properly represented, even in the new version AW 24.2

This problem is still there:
Given this number “12345678.06”, while using the fr_BE locale and a number format switch like this # “#.##0,00” the output differs between the two versions.

  • Output is incorrect in AW 24.2.0, output is: $1.234.567.806,00 (it’s like it considers the dot as being thousands separator from the input value)

Have I missed something, by any chance?
Thank you.

@oborza The issue has been closed as Not a Bug. Here is the analysis:

First things first. The comment in the sample document says:

fr_BE locale default separators
decimal = <comma>
thousands = <space>

It’s not correct (at least for .net and Windows). The number group separator (aka thousands separator) is a dot.

Given this number “12345678.06”, while using the fr_BE locale and a number format switch like this # “#.##0,00”
Output is incorrect in AW 23.7.0, output is: $1.234.567.806,00 (it’s like it considers the dot as being thousands separator from the input value)

Your guess is correct. The dot is considered as thousands separator because it is actually thousands separator in Fr-Be. You should pass the value of the numeric type (double/float/decimal) or at least use the correct decimal separator in the string value.

Formatting like this # “# ##0,00”, using space separator for thousands – doesn’t work, only adds the separator to the first thousands group, why? Output: $12345 678,06

We can not use any char as thousands separator except defined one in current culture (the dot in Fr-Be). MS Word and AW consider only separators from current culture settings and treat all others as constant symbols with no special meaning. So the space is preserved in output as is.

Format, remove spaces, thousand separator as # “ 0,00” – doesn’t work! How to do the same as #WORDSNET-17, but using as thousand separator, since separator seems that it doesn’t work when used in a switch like this.

There is no way to format results with different separators using only built-in functionality. But there are two APIs that you may use:

Option 1. Document.FieldOptions.FieldUpdatingCallback:

document.FieldOptions.FieldUpdatingCallback = new FieldUpdatingCallback();

public class FieldUpdatingCallback : IFieldUpdatingCallback
{
    public void FieldUpdating(Field field)
    {
        defaultCulture = CultureInfo.CurrentCulture;
        if (string.IsNullOrEmpty(field.Format.NumericFormat))
            return;

        // The condition is for demonstration purposes only
        if (field.Format.NumericFormat.Contains(" "))
        {
            // Modify an existing culture or create a new one from scratch with expected separators
            CultureInfo cultureInfo = new CultureInfo("fr-BE");
            cultureInfo.NumberFormat.NumberGroupSeparator = " ";
            CultureInfo.CurrentCulture = cultureInfo;
        }
    }

    public void FieldUpdated(Field field)
    {
        CultureInfo.CurrentCulture = defaultCulture;
    }

    private CultureInfo defaultCulture;
}

Option 2. Document.FieldOptions.ResultFormatter:

document.FieldOptions.ResultFormatter = new ResultFormatter();

public class ResultFormatter : IFieldResultFormatter
{
    public string FormatNumeric(double value, string format)
    {
        // Implement custom number formatting here        
    }

    public string FormatDateTime(DateTime value, string format, CalendarType calendarType)
    {
        return null;
    }

    public string Format(string value, GeneralFormat format)
    {
        return null;
    }

    public string Format(double value, GeneralFormat format)
    {
        return null;
    }
}

Format, thousands separator, # “# ### ### ### ### ### ##0,00" – works but adds spaces between the currency sign and value, which is not what I want.

MS Word and Aspose.Words insert a space in place of # if there is no corresponding digit in the field value.
MS Support: # This format item specifies the requisite numeric places to display in the result. If the result does not include a digit in that place, Word displays a space.

The behavior is the same in AW 21.5 for .NET.

Thanks for your reply, for separators I’ve understood the problem, I’ll use custom formatting.

What I’m more interested in, is this one and main issue that I’ve mentioned:
For this case, formatting using the fr-BE locale uses the standard separators, comma for decimal and dot for thousands (regardless of my initial comment in the document that you refer to)

Given current usage of AW 21.5, where formatting works properly by passing the value as a string too, how would I be able to update to newer AW versions if this is a disruptive change (and a change in behavior among AW versions which I haven’t seen documented) ?
Why does it work in AW 21.5, and then the same behavior breaks in newer versions?

@oborza To apply formatting to the passed string "12345678.06" the string should be parsed to double/float/decimal value first. If in the string incorrect decimal separator is used for the given culture the string will be parsed improperly and incorrect result will be shown.

@alexey.noskov I understand that parsing it to double will make it work, but even though you choose not to answer my questions, I’ll emphasize this again: this works well in Aspose Words 21.5, as is, with the dot separator, and ever since behavior has changed (in newer versions), but there’s no mention about it!
Thanks. Should I expect this to be fixed?

@oborza The issue has been closed as Not a bug and no additional fixes will be provided. The behavior of old 21.5 version of Aspose.Words for Java is incorrect and does not match 21.5 version of Aspose.Words for .NET, which is the main product. So it looks like you relied on the behavior, which is actually a bug in old version of Aspose.Words for Java.