Right, not a FOP problem, but on the other side, XSL-FO also uses Java's
DecimalFormat notation for formatting page numbers. Fortunately, we
don't have page numbers that large. :-) Anyway, looks like Java has a
problem with these numbers. Xalan probably simply uses the DecimalFormat
and relies on Java to do everything right. Look at this:
public class DecimalFormatTest extends TestCase {
public void testDecimalFormat() throws Exception {
DecimalFormat df = new DecimalFormat("###,###.00;###,###.00CR");
//These check out ok:
assertEquals("456,787.00CR", df.format(-456787.00));
assertEquals("890,123,456,787.00CR", df.format(-890123456787.00));
assertEquals("7,890,123,456,787.00CR", df.format(-7890123456787.00));
assertEquals("67,890,123,456,787.00CR", df.format(-67890123456787.00));
assertEquals("567,890,123,456,787.00CR",
df.format(-567890123456787.00));
assertEquals("4,567,890,123,456,787.00CR",
df.format(-4567890123456787.00));
assertEquals("34,567,890,123,456,788.00CR",
df.format(-34567890123456788.00));
//The two next checks fail:
assertEquals("34,567,890,123,456,786.00CR",
df.format(-34567890123456786.00));
assertEquals("34,567,890,123,456,787.00CR",
df.format(-34567890123456787.00));
}
}
To me it looks like Java's double datatype has trouble keeping up with
precision with these large numbers.
On 18.04.2006 11:02:37 Florent Georges wrote:
> Ian & Chris wrote:
>
> > I am currently trying to format a large number (19v2) in a
> > report, the format-number function seems to do incorrect
> > formatting when it deals with large numbers, and an example
> > follows:
>
> > <xsl:value-of select='format-number(-34567890123456787.00,"###,###.00
> > ;###,###.00CR")'/>
>
> This is not related to FOP, but to your XSLT processor. I suggest
> you to post either to the XSL List (fron Mulberrytech) or to the list
> of your XSLT processor.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
