[Bug 891457] [Regression] Chinese emulated Bold uneven and no longer works

[bugzilla at redhat.com]

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

Hin-Tak Leung <htl10 at users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(htl10 at users.sourc |
                   |eforge.net)                 |

--- Comment #8 from Hin-Tak Leung <htl10 at users.sourceforge.net> ---
(In reply to comment #6)
> It seems working fine on f18 TC4. please try again.

(In reply to comment #7)
> and it works fine on f17 + new fontconfig. I don't think it is a big in
> fontconfig anyway.

Argh, I forgot to mention that I have always been running 32-bit R on a 64-bit
system (there is an advantage on memory footprint, and there used to be a
substantial speed advantage but I am told it isn't anymore). This seems to be
an important detail to see this bug - if I run the 64-bit R, then the problem
disappears.

Is it possible to see if you can reproduce this on a 32-bit F18 system?

In any case, this seems to apply only to 32-bit R (on a 64-bit system). Also,
now that I can get the desired outcome with 64-bit R, I can see that the
"CairoFont" font name issue is a red-herring (it just seems that newer cairo
behaves differently), as both the correct and icorrect pdf have that as the
emboldened font name, but that the "correct" pdf and the "incorrect" pdf differ
in the glyph stream data of that font; the other two fonts have the same glyph
stream data and only differ slightly in the subset prefix and rounding in
fontbox/ascent, etc.

If you can reproduce this on 32-bit F18 system, probably should reassign this
to cairo/freetype or somebody who knows about glyph-level font data.

-- 
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=Aaf7eFJrDL&a=cc_unsubscribe