GNOME Bugzilla – Bug 309209
strange behavior on format-number()
Last modified: 2016-04-30 14:19:14 UTC
Version details: from PHP installation ver 5.04 windows i am using the xslt functionality of PHP 5. Running the following xsl i get some faulty results: format-number($number, '- 0;0') with negativ numbers i get an attached '6' format-number(-13, '- 0;0') => '136' format-numer($number, '- 0') the '-' is not interpreted as negativ prefix format-number(-13, '- 0') => '-- 13' format-number( 13, '- 0') => '- 13' format-number($number, '-a0.;b0') i get an error stating 'xmlEscapeEntities : char out of range' on negativ numbers with format-number($number, '-a0;b0') i don't (note the missing decimal separator) format-number($number, '-a0;-b0') i get an error stating 'xmlEscapeEntities : char out of range' on negativ numbers with format-number($number, 'a0;-b0') i don't format-number($number, ':0;:0') i get the negativ prefix '-' on negativ numbers with format-number($number, 'a0;b0') i don't format-number($number, '-:0;:0') works also as expected format-number(-13, ':0;:0') => '-:13' format-number($number, '') as of the BNF from JDK 1.1 this should be considered as an error pattern := subpattern{;subpattern} subpattern := {prefix}integer{.fraction}{suffix} prefix := '\\u0000'..'\\uFFFD' - specialCharacters suffix := '\\u0000'..'\\uFFFD' - specialCharacters integer := '#'* '0'* '0' fraction := '0'* '#'* now the test-code joerk ------------ <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/TR/REC-html40" xmlns:data="http://dataland.de/data"> <data:formats> <data:format value="0;0" /> <data:format value="- 0;0" /> <data:format value="- 0" /> <data:format value="-a0.;b0" /> <data:format value="-a0;-b0" /> <data:format value="-a0;b0" /> <data:format value="a0;-b0" /> <data:format value="a0;b0" /> <data:format value=":0;:0" /> <data:format value="-:0;:0" /> <data:format value="" /> </data:formats> <data:numbers> <data:number value="-12.9" /> <data:number value="-2.7" /> <data:number value="-0.9" /> <data:number value="-0.3" /> <data:number value="-0.03" /> <data:number value="0" /> <data:number value="0.4" /> <data:number value="1.8" /> <data:number value="12" /> </data:numbers> <xsl:variable name="nl"> <xsl:text> </xsl:text> </xsl:variable> <xsl:template match="/"> <table><xsl:value-of select="$nl"/> <tr><xsl:value-of select="$nl"/> <xsl:for-each select="document('')/*/data:formats/data:format"> <th> <xsl:value-of select="@value"/> </th><xsl:value-of select="$nl"/> </xsl:for-each> </tr><xsl:value-of select="$nl"/> <xsl:for-each select="document('')/*/data:numbers/data:number"> <xsl:variable name="number" select="@value"/> <tr><xsl:value-of select="$nl"/> <xsl:for-each select="document('')/*/data:formats/data:format"> <td> <xsl:value-of select="format-number($number, @value)"/> </td><xsl:value-of select="$nl"/> </xsl:for-each> </tr><xsl:value-of select="$nl"/> </xsl:for-each> </table> </xsl:template> </xsl:stylesheet>
testing with xsltproc from libxslt-1.1.14.win32 the error with the additional 6 as well as the ones stating 'xmlEscapeEntities : char out of range' all result in trashy output: (-12.9, '- 0;0') => 13Y (-12.9, '-a0.;b0') => b13.∟ (-12.9, '-a0;-b0') => -b13] The format pattern '0;0' also results in output containing a negativ prefix (as it did also in the test i run under php) ... all this trouble just by migrating from php4 to php5 :(
Working on a report like this is a little difficult for me. First, I can only address problems which are clearly within the libxslt/libxml2 libraries (i.e. the fact that it fails under PHP is out of my 'jurisdiction') - a failure under xsltproc is indisputable. Second, my knowledge of XSL is limited - it would make it much easier for me if you include 'expected' results. Nevertheless, I found and fixed the problem which caused "trashy output" (because of a pointer error, the code was accessing unintialised memory). The fixed code is in CVS, and I'm attaching the output of "xsltproc bug.xsl bug.xsl". Please review it and see which lines you feel are now incorrect. Bill
Created attachment 48475 [details] xsltproc output
William, unfortunately i'am not very much in compiling ... so it is not so easy for me to crosscheck your changes. Otherwise you posted your new results ;-) The readability of the output is not the best when dealing with xsltproc - so i changed the xsl test-file. You also wanted the correct values to be stated though i listed all the bugs in my first error report. Please run 'xsltproc bug.xsl bug.xsl' to see the results. When running 'xsltproc --stringparam only errors bug.xsl bug.xsl' all passing results aren't listed anymore. Please note the the result checking relies on the working cases of the format-number function. As of the xslt standard a precise description for the number formatting is to be found in the api-docs of the JDK 1.1. Thes
Created attachment 48482 [details] xsl file for testing This xsl file lists the mentioned bugs by running the formatting method on a matrix of formatpatterns and numbers. By passing the parameter 'only' with a non empty value the output contains only the errors.
Created attachment 48483 [details] The spec for the format patterns The xslt-spec states: --------------------- The format pattern string is in the syntax specified by the JDK 1.1 DecimalFormat class. The format pattern string is in a localized notation: the decimal-format determines what characters have a special meaning in the pattern (with the exception of the quote character, which is not localized). The format pattern must not contain the currency sign (#x00A4); support for this feature was added after the initial release of JDK 1.1. --------------------- JDK 1.1 actually has reached "End Of Life" (see http://java.sun.com/products/archive/j2se-eol.html) so i posted a copy of the api-part
Created attachment 48487 [details] Results of format-number testing Thanks for the further info. Attached are the results of processing the second xsl file with the current CVS source. It appears that +ve values are basically ok (except for a blank format), but -ve values have several discrepancies. I'll try to clear these problems over the next few days.
Created attachment 48496 [details] xsl file for testing Actually i am not sure how the output should be for negativ numbers if there is no special negativ pattern but a '-' in the pattern. Crosschecking with sablotron the way libxslt handles it might be correct. Looking at the output (the on you updated recently) i have to admit, that i made a mistake. The integer pattern should alwas be take from the positive part. So for '-a0.;b0' the output is correct. I added some testcases for this and saw that the suffix of negativ subpatterns is ignored. So the error can be reduced to cases where a negativ subpattern has to be used (which only takes place for negative numbers). If there is no negativ subpattern libxslt runs fine. The question whether libxslt should be more strict in patternchecking or not might be solved in an enhancement-bug ... Joerk
Created attachment 48502 [details] xsl file for testing More tests and more errors. I spent some time on the pattern-syntax after searching a pattern error thrown by libxslt. libxslt doesn't pay attention to the escape character ' (the apostroph) libxslt doesn't know the default per-mille sign wich is the unicode character U+2030 I added more test cases and made use of the third parameter, were a decimal-format could be specified. As many errors result in a fallback to a default format, i testet the results against a default evaluation. Have fun. Is it possible to post me an updated windows dll? Though the bug i have to cope with isn't solved yet.
The apostrophe and per-mille issues should be fixed with the following commit (from 2005): https://git.gnome.org/browse/libxslt/commit/?id=f39f519162c185a0ecba9476d1bbea1db1b8ef93 The latest test case from Joerk Behrends only reports failures for the following xsl:decimal-format <xsl:decimal-format name="other" decimal-separator="-" grouping-separator="#" infinity="too much" minus-sign="%" NaN="NaN" percent="!" per-mille="‰" zero-digit="a" digit="b" pattern-separator=";"/> and the patterns a0b -a0.0#;b0'0c But both of these patterns are invalid as they contain special characters in the suffix. Consequently, libxslt reports xsltFormatNumberConversion : error in format string 'a0b', using default xsltFormatNumberConversion : error in format string '-a0.0#;b0'0c', using default So it seems that the commit mentioned above fixed all of the actual issues.