[Bug 891457] uneven emulated Bold/Slant for subsetted large fonts

[bugzilla at redhat.com]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=891457

--- Comment #32 from Hin-Tak Leung <htl10 at 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=FBgBinwhjM&a=cc_unsubscribe