Jeremias Maerki wrote:
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.
It's a problem with the limit of the precision of doubles, methinks. OP,
if you need this level of precision, you can either use
java.math.BigDecimal, if you really insist on courting trouble, or do
what everyone *should* do with currency - represent it as a long in the
smallest unit of the currency; in this case, one hundredth of a rupiah,
whatever that is. Using floating point numbers to represent currency is
fairly common, but nonetheless ridiculous for being common.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
