We want you to contribute!
This forum is a moderated environment.
We try to keep it neat and tidy. In order to access the forum content we would like you to either login or register.
When creating i.e. a border for an object, on my Swedish version of WIndows 7 I have to enter a decimal comma instead of dot like this for the parser to work:
<s:Style applied-type="pdf:Cell" >
<s:Border width="0,1" color="black"/>
<s:Font family="Helvetica" size ="7"/>
Would this work correctly on a client computer running an English version of Windows? Otherwise I think there is a problem with the parsing of decimal numbers.. An invariant culture should be used in the parsing of the decimal value.
Can anyone confirm thisbeing an issue or not?
Regards / Björn
This is a really good callout. And something we need to sort.
Yes - in all probability the 0,1 value will not be correctly parsed on machines running the English version of Windows (for example).
So I have to ask - as a native Swedish developer what would you expect here. To enter the number as invariant - e.g 0.1 rather than current culture 0,1
Would you do that it in CSS or HTML?
Would you expect the same with dates?
Well, I don't find anything more frustrating than the fact that MS at some point elected to translate the VBA commands found in MS Office... This means I cannot use expected function names like =FIND() in the sheet formula, instead I'm supposed to use the Swedish word =HITTA()... Unless of course I'm using the VBA from code, then it is the English command again.. Really annoying!
Therefore; you should definitely go with the culture invariant version... Equal for all, on all platforms... In C# (In Studio) I'm also using the culture invariant style...
I have to say I really appreciate your product! It is really easy to use and in only one day of playing around I have managed to create exactly the reports I wanted! Great work you guys!!
We will apply this logic in the forthcoming release - Invariant for parsing, but allow an explicit override (parser-culture="...") in the processing instructions.
Until this fix is in place I'm afraid I think you will be stuck with whole point values (1/72nd of a point).