Re: Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

On 9/5/21 7:26 PM, Solomon Peachy wrote:
> On Sun, Sep 05, 2021 at 06:16:10PM -0400, Robert Krawitz wrote:
>> Sigh...have to figure out how to fix this.  Maybe we have to allow 
>> something like a millipoint of slop.  Interesting that it seems to 
>> have only hit the dyesub printers; is the issue that those are the 
>> only ones with non-integer widths (in points)?
> 
> Yeah, I can't speak for every other family but inside the dyesub driver, 
> all dimensions are specified in terms of pixels, but converted to points 
> for external consumption.
> 
> I think it's reasonable to truncate anything smaller than a millipoint, 
> though just patching that failing test to allow for a little slop seems 
> like a bandaid when there very may well be other related lurking issues that
> are ultimately due to a platform-specific FP semantics problem.

I don't want to patch the test.

> So I question whether Gutenprint is relevant for a >20-year-old 
> Pentium3-era PC -- and this OpenSUSE build is actually targeting even 
> older Pentium1-era systems that a $5 Raspberry Pi Zero would easily run 
> circles around.
> 
> Perhaps the correct thing to do is force these older targets to use 
> "correct" IEEE754 FP math through some extra GCC flags (-ffloat-store 
> might be sufficient), which would hurt performance (on an already 
> relatively glacial platform) but would mean we'd not need to make 
> otherwise unnecessary algorithmic spelunking..

I agree.  It's exactly the kind of change that might break something else.  I want to fix the
problem, but it's more important not to break existing platforms.

>   https://gcc.gnu.org/wiki/x87note
>   https://gcc.gnu.org/wiki/FloatingPointMath

Johannes, could you try that suggestion?  If it works, we'll look into how to make the change if we
safely can.