Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #32 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #31)
(In reply to comment #30)
So we agree perfectly with freetype 2.4.9 32-bit or 64-bit outcome, but not 2.4.11 32-bit outcome. How did you build yours?
I only tested with 64-bit. I don't have my 32-bit machine here right now and gcc -m32 doesn't seem to work on Debian.
Oh, but I never did have a problem with 64-bit of everything (freetype 2.4.10/2.4.11) - and only with 32-bit of 2.4.10 where it was first seen, and a different reversed-video look with 32-bit 2.4.11. So for me, it has always been *only* 32-bit being broken, until I tried the earlier 64-bit 2.4.9 .
(fedora 18 ships 2.4.10, the 2.4.9 url is in the compile-farm alpha/beta-build archive, koji, from 9 months ago).
This does not rule out cairo passing indetermined parameters to freetype (like the signed/unsigned load_flags which are ~mask'ed, I mentioned earlier) though.
Does it make any difference if you change the signed to unsigned and run the testcase?
It did not - but that's just one mistake I noticed. There are others places where cairo's internals does not work in the same philosophy as freetype (I am not saying which is right/wrong - just different). freetype is usually very clear about what size of paramaters are, and *no bigger*, because at places it does fixed-precision maths without floating-point operations (all those FIXED.. macros). e.g. I see places in cairo - in the bits where it interacts with freetype, such as the cairo-type1-fallback.c, where it uses 'unsigned long' types... now, 'long' is 32-bit on 32-bit platforms but 64-bit on 64-bit platforms...
So we are still back to square one, 32-bit run path does not work correctly.