[
https://issues.apache.org/jira/browse/PDFBOX-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13823546#comment-13823546
]
Michael Klink commented on PDFBOX-1778:
---------------------------------------
As the spec mentions floats down to 1.175 × 10^(-38), setting the maximum
digits to 10 (as in Tilman's code) does not suffice. But in combination with
BigDecimals, it can be set way higher:
{code}
DecimalFormat formatDecimal =
(DecimalFormat)NumberFormat.getNumberInstance();
formatDecimal.setMaximumFractionDigits( 300 );
formatDecimal.setGroupingUsed( false );
DecimalFormatSymbols symbols = formatDecimal.getDecimalFormatSymbols();
symbols.setDecimalSeparator( '.' );
formatDecimal.setDecimalFormatSymbols( symbols );
float[] testFloats = new float[] {
1000000f,
1000f,
1f,
0.001f,
0.000001f,
0.000000001f,
0.000000000001f,
0.000000000000001f,
0.000000000000000001f,
0.000000000000000000001f,
0.000000000000000000000001f,
0.000000000000000000000000001f,
0.000000000000000000000000000001f,
0.000000000000000000000000000000001f,
0.000000000000000000000000000000000001f,
0.000000000000000000000000000000000000001f
};
for (float f : testFloats)
{
System.out.println (f);
System.out.println (formatDecimal.format(f));
System.out.println (formatDecimal.format(new
BigDecimal(String.valueOf(f))));
System.out.println();
}
{code}
results in
{noformat}
1000000.0
1000000
1000000
1000.0
1000
1000
[...]
1.0E-33
0.000000000000000000000000000000001000000023742228
0.000000000000000000000000000000001
1.0E-36
0.0000000000000000000000000000000000010000000359391298
0.000000000000000000000000000000000001
1.0E-39
0.0000000000000000000000000000000000000010000002153053333
0.000000000000000000000000000000000000001
{noformat}
The main disadvantage:being that first executing toString, then building a
BigDecimal, then formatting that object and throwing it away is quite a bad
resource abuse.
PS: Is there a need why the DecimalFormat is created anew each time? Ok,
decimal formats are generally not synchronized, but external synchronization or
ThreadLocal use would suffice...
> Rounding issue in generated PDF file
> ------------------------------------
>
> Key: PDFBOX-1778
> URL: https://issues.apache.org/jira/browse/PDFBOX-1778
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel, Signing
> Affects Versions: 1.8.3
> Reporter: vakhtang koroghlishvili
> Assignee: Andreas Lehmkühler
> Priority: Critical
> Fix For: 1.8.3, 2.0.0
>
> Attachments: extreme-values-red.pdf, extreme-values-red.png,
> extreme-values.pdf, extreme-values.png, original.pdf, saved.pdf
>
>
> We have PDF file which was signed by some other application.
> When we try to sign it with PDFbox, previous revision is damaged.
> We did some investigations and found such problem:
> (question on stackoverflow is here:
> http://stackoverflow.com/questions/19903884/pdf-document-is-modified-by-another-revision/19905271?noredirect=1#19905271
> )
> Some PDF tags are changed in new revisions.
> For example values of following tags:
> /WhitePoint
> /Gamma
> /Matrix
> are changed from values like this: 0.9505
> to values like this: 0.9505000114
> We think this is problem of converting float/double inside COSFloat.
> Following code just opens and saves PDF file and this operation changes
> values of mentioned text:
> public void saveTo(String sourceFile, String destFile) throws Exception{
> PDDocument doc = PDDocument.load(new FileInputStream(sourceFile));
> doc.save(new FileOutputStream(destFile));
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
