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

bugzilla at redhat.com bugzilla at redhat.com
Sat Jan 5 00:15:12 UTC 2013

Product: Fedora

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

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

More information about the fonts-bugs mailing list