[gs-bugs] [Bug 691328] non deterministic behavior in comparefiles/Bug688807

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Sun Jul 25 08:27:09 UTC 2010


Chris Liddell <chris.liddell at artifex.com> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #5 from Chris Liddell <chris.liddell at artifex.com> 2010-07-25 08:27:05 UTC ---

I revisited this last night, after SaGS comment and (now I understand things a
little better!) I take the point.

Ray, if you want to review and revise how this stuff works at the clist level,
I'm fine with that, but the "core" of the problem is that the clist code, and
possibly elsewhere, quite reasonably only expect bitmaps originating from
within Ghostscript itself. Now, however, it can receive bitmap data from FAPI
which originates in the font scaler/renderer library which happens to be in use
at the time (by default, Freetype). My concern is that we've seen the clist
related problem, but there may be other places that make the same assumption,
and I would rather not try to track them all down!

The problem here is that Freetype uses a different scanline alignment to

Thus I suggest that the proper solution for *this* problem (regardless of other
improvements to be made elsewhere) is to have FAPI ensure that the bitmap is
correctly formatted for Ghostscript before calling GS operations on it.

I wrote the code to do this last night, and I have a longer term solution for
the default Freetype implemenation (which will provide other benefits if it
goes ahead) but I need to discuss it with Werner as it means changes to

Unless there are objections, I'll commit the FAPI changes.

Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the gs-bugs mailing list