I just bought aspose.words for .NET and it works very well so far. I do have a question about the formatting of the mergefield codes. I am testing on a machine where the culture settings are dutch (nl-NL). However, when I apply dutch based formatting (with a comma as decimal separator) to numeric field that does nog work. It only works correctly when I use the US format (with a dot as decimal separator). Is this by design?
I would prefer that the merge makes use of the current locale of the machine, so that users of my application can use the same formatting strings as would work normally when they use it in Word.
Please be a little more specific in describing your problem. Where do you apply dutch based format - in Windows Control Panel or in MS Word? How it is connected to merge field codes? Does it occur before or after merging? And why is your post is called "Culture settings for merge picture format"?
It will be also very helpful if you would provide a code snippet and a test document illustrating the problem.
The dutch based format is set in Windows Control Panel.
When I create a new Word document in Word and put in the following test field: {=10 \# 0,00 \* MERGEFORMAT \* MERGEFORMAT} then the result is '10,00' which is right, according to the dutch settings (komma as decimal separator).
When I create another Word doc in Word and put in the following fields: MERGEFIELD plaatsing_brutoloon \# 0.00 \* MERGEFORMAT MERGEFIELD plaatsing_brutoloon \# 0,00 \* MERGEFORMAT
and I merge this document using aspose.words and a dataset then the results are: 10,00 010
So it seems that aspose.words is not using the dutch settings. I personally don't mind, but I would like to get rid of this complexity for my end users.
Oh, I see now. Well, it probably can be fixed. There is one thing that concerns me though. Currently Aspose.Words interpretation of the numeric picture switch is culture invariant. That means that the same template gives correct results in different cultures. If we follow your proposal than the template prepared in one culture will give incorrect results when merged on a computer with another culture. I don't think it will be good.
I will contemplate a little bit further on the issue. Maybe there is still a solution that can reconcile both current implementation and your proposal.
Meanwhile, can you send me a template with the merge field and a numeric picture switch prepared in dutch culture. It will help me in my research.
My server is physically located in the US and most of my users are US-based. So when they use numeric picture formats for US currency, their merges work fine.
However, I now have a user based in Germany and he would like to use the German Euro formatting (using “.” for the thousands-separator and “,” for the decimal separator) and Words is not producing that result by simply changing the picture format.
When I read your original post, I hoped that being “culture invariant” would allow the numeric picture formats to work either for US or European formats, but perhaps not.
At the moment Aspose.Words requires picture format switches in merge fields to be in the US (InvariantCulture) format.
This is because Aspose.Words uses standard .NET functions to format values. Yes, the standard .NET functions require InvariantCulture format strings. The output will be different of course depending on the current culture on the machine, but the input format string must be in the InvariantCulture.
Since Aspose.Words relies on these .NET functions it therefore works this way - requires format switches to follow the InvariantCulture.
Of course it would be nice to allow Aspose.Words to properly handle format switches in all cultures, but this will be a significant effort for us which we are not prepared to do right now. Also, as Vladimir correctly pointed out earlier - if Aspose.Words understood format switches in different cultures - you would have to set the proper culture before executing mail merge. Aspose.Words will probably not be able to detect a proper culture. It will also not be easy to detect the proper culture for you. It is good if you can be sure all documents will come in certain culture, but what if they come in different cultures?
My thinking is that Microsoft making format switches different for different cultures was a design mistake. Basically this is localizing too much, localizing things that should not be localized. Another great (bad) example is localizing names of fields or names of functions in MS Excel. What do you think of a function AVG becoming СРЗНАЧ in Russian version? Same goes for format switches.
The best option for you is to go through your documents and change format switches to use InvariantCulture format. In fact, you can write a program in Aspose.Words to go and do that for you automatically.