[poppler] PDF to PPM: Page height differs between 32bit and 64bit systems

[Dyweni - Poppler]

On 2014-05-14 13:31, James Cloos wrote:
>>>>>> "D" == Dyweni  <- Poppler <7FdqWGq4fE8x at dyweni.com>> 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