On 2014-05-14 13:31, James Cloos wrote:
"D" == Dyweni <- Poppler <[email protected]>> writes:
D> Hi,
D> I've traced the problem back to line 501 in the same file 'pg_h =
pg_h
D> * (y_resolution / 72.0);'
The %a option in printf(3) would be useful, too.
I added some %a options like this:
-----
printf("x_resolution = %a\n", x_resolution);
printf("y_resolution = %a\n", y_resolution);
printf("pg_w = %a\n", pg_w);
printf("pg_h = %a\n", pg_h);
pg_w = pg_w * (x_resolution / 72.0);
pg_h = pg_h * (y_resolution / 72.0);
printf("pg_w = %a\n", pg_w);
printf("pg_h = %a\n", pg_h);
-----
And I get this:
----
x_resolution = 0x1.2cp+7
y_resolution = 0x1.2cp+7
pg_w = 0x1.32p+9
pg_h = 0x1.8cp+9
pg_w = 0x1.3ecp+10
pg_h = 0x1.9c80000000001p+10
----
Rather than 32bit vs 64bit, this is likely a '387 vs ieee754 issue.
The fp math on the 387 was done with 64bit significand for any input,
and the modern x86 processors emulate that when using the 387
instructions.
Anything doing the calculations on _Float64 (52+1 bit significand) will
see more rounding issues.
I'd expect all non-x86 systems to agree with your 64bit results,
notwithstanding whether they are 32- or 64-bit.
Given the higher internal precision of the 387 calculations, it is
reasonably to presume tha 1650 is the more accurate result. Which
implies that something more complicated than ceil() is desired.
Feeding those printf("%.64f", ...)) results into printf(1), I get
0xc.e4p+7 vs 0xc.e400000000008p+7.
For a _Float64 that is a difference of the least significant bit.
Maybe casting the double to a float and using ceilf(3) would be the
right solution?
Switching from '(int)ceil(pg_h)' to '(int)ceilf((float)pg_h)' is
returning 1650 on both systems.
Thanks,
Dyweni
_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler
