Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(htl10@users.sourc | |eforge.net) |
--- Comment #8 from Hin-Tak Leung htl10@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.