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

[jsmeix <js...@su...>]

Hello,

sorry for the delay - I was busy with other tasks.

On 2021-09-06 01:26, 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.
> 
> 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.

I have no influence for what exact 32-bit x86 architecure
packages for openSUSE_Tumbleweed for 32-bit x86 are built.
I assume "i586" was chosen intentionally and I guess
it was chosen as some generic most common most basic thing
so that packages that are built this way reall work on
any 32-bit x86 hardware that is still "out there" without
restrictions to only some "newer" 32-bit x86 hardware.
Bottom line:
I cannot change that so I have to use it as is.

> 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..

Unfortunately -ffloat-store does not help.

I made a separated gutenprint53t package at
https://build.opensuse.org/project/show/home:jsmeix

There -ffloat-store is set if arch is not x86_64 see
https://build.opensuse.org/package/view_file/home:jsmeix/gutenprint53t/gutenprint53t.spec?expand=1

As far as I see from the build log -ffloat-store is actually used
during compile:
https://build.opensuse.org/public/build/home:jsmeix/openSUSE_Tumbleweed/i586/gutenprint53t/_log

In
https://build.opensuse.org/project/show/home:jsmeix
I made a separated gutenprint53-testing Package
with much reduced set of PPDs that get tested
and its build log for openSUSE_Tumbleweed i586
shows basically same failures:
https://build.opensuse.org/public/build/home:jsmeix/openSUSE_Tumbleweed/i586/gutenprint53-testing/_log


I am not a C expert and even less an expert in the details
of using float data types in C.

 From my own experience about 30 years ago I remember
that in practice
"there is no such thing as 'equal' with float data types".

I.e. code that is based on 'float1 == float2' cannot work
reliably in general because even if float1 and float2
must me mathematically identical it does not mean their
representations as a limited sequences of bits are same.

This is because e.g. the least significant bits could get
arbitrarily different because of truncating/rounding during
different calculations for float1 versus float2 compared
to mathematically exact values and other things like that.

E.g. you may have a look at

https://stackoverflow.com/questions/16839658/printf-width-specifier-to-maintain-precision-of-floating-point-value/19897395

So what I did about 30 years ago was to implement my own
specific fuzzy comparisons for the precision that I need
like instead of 'float1 == float2' I used something like
fuzzy_float_equal( float1, float2 )
or instead of 'float1 < float2' I used something like
fuzzy_float_less_than( float1, float2 )
and so on.

I don't know if nowadays IEEE standards could help to avoid
that one had to implement such awkward things - i.e. help
to get what is mathematically right also with float data types.


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer