Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Bug ID: 891457 Summary: [Regression] Chinese emulated Bold uneven and no longer works Product: Fedora Version: 18 Component: fontconfig Severity: unspecified Priority: unspecified Reporter: htl10@users.sourceforge.net
Created attachment 671807 --> https://bugzilla.redhat.com/attachment.cgi?id=671807&action=edit the test.Rnw file mentioned
Description of problem: R has a way of generating pdf plots with Chinese annotations via cairo. The plot titles are in sans:style=Bold, I believe. In F17 WenQuanYi Zen Hei is subsetted and embedded as truetype. But in F18, an unknown bitmap is embedded as CairoFont-?-? .
Version-Release number of selected component (if applicable): fontconfig-2.10.2-1.fc18.x86_64 cairo-1.12.8-1.fc18.x86_64 freetype-2.4.10-2.fc18.x86_64
How reproducible: Always.
Steps to Reproduce: 1. run "R --vanilla CMD Sweave test.Rnw" (test.Rnw will be attached) 2. look at the test-002.pdf generated. 3.
Actual results: Uneven boldening title
Expected results: even boldening of the title
Additional info: You need to run R under R to do this ; xvfb-run could be used for headless system.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #1 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 671809 --> https://bugzilla.redhat.com/attachment.cgi?id=671809&action=edit find /etc/fonts -ls listing
find /etc/fonts -ls
listing - I have carefully done
find /usr/share/fontconfig -type f | xargs rpm -qf | sort | uniq | xargs rpm -V
and removed all local customizations
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #2 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 671810 --> https://bugzilla.redhat.com/attachment.cgi?id=671810&action=edit "find /usr/share/fontconfig -ls" listing
"find /usr/share/fontconfig -ls" listing
I think this should show all the fonts I have installed (the last listing shows which are active).
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #3 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 671811 --> https://bugzilla.redhat.com/attachment.cgi?id=671811&action=edit test-002.pdf generated by a clean account
test-002.pdf generated by a clean account, and stock configs.
generated with
xvfb-run R CMD Sweave test.Rnw
from an account which does not have its own .fonts.conf . You can see two or three of the glyphs are bolden more than others.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #4 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 671812 --> https://bugzilla.redhat.com/attachment.cgi?id=671812&action=edit test-002.pdf from an account which has a font.conf which avoid the Droid fonts.
test-002.pdf from an account which has a font.conf which avoid the Droid fonts.
this is how I first noticed it - it is more serious if you have a font.conf which avoid the droid fonts:
----------- <selectfont> <rejectfont> <pattern> <patelt name="family"><string>Droid Sans</string></patelt> </pattern> </rejectfont> <rejectfont> <pattern> <patelt name="family"><string>Droid Serif</string></patelt> </pattern> </rejectfont> <rejectfont> <pattern> <patelt name="family"><string>Droid Sans Mono</string></patelt> </pattern> </rejectfont> </selectfont> -----------
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #5 from Hin-Tak Leung htl10@users.sourceforge.net --- I have already tried a few things:
- setting FC_DEBUG (cannot make sense of the outcoming info - some help instruction would be appreciated),
- strace -f ("R CMD SWeave" do fork - in any case, only the sans ascii fonts and [Droid or WQY] are opened).
but none produces acceptable result.
please feel free to assign it as cairo or freetype problem as appropriate. Since removing .fonts.conf (and switching between Droid and WQY) produces bad results from a clean account with headless xvfb-run, I assume this is a system-wide problem not due to customization; I suspect the problem is probably somewhere between cairo and freetype.
Sorry I don't have a simplier non-R way of showing the same problem - pango-view seems to do okay/correct.
Also the CairoFont-?-? font names were never seen under F17.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(htl10@users.sourc | |eforge.net)
--- Comment #6 from Akira TAGOH tagoh@redhat.com --- It seems working fine on f18 TC4. please try again.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #7 from Akira TAGOH tagoh@redhat.com --- and it works fine on f17 + new fontconfig. I don't think it is a big in fontconfig anyway.
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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |otte@redhat.com Component|fontconfig |cairo Hardware|x86_64 |i686 Assignee|tagoh@redhat.com |otte@redhat.com
--- Comment #9 from Akira TAGOH tagoh@redhat.com --- Indeed I can confirm this issue on i686 box and even with C code and it works on x86_64. so reassigning to cairo.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #10 from Akira TAGOH tagoh@redhat.com --- Created attachment 674513 --> https://bugzilla.redhat.com/attachment.cgi?id=674513&action=edit the code to reproduce
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #11 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #10)
Created attachment 674513 [details] the code to reproduce
Just a couple of comments - the last working cairo was the one in F17, cairo-1.10.2-7.fc17 ; also the problem is independent of the font used - "WenQuanYi Zen Hei" or "Droid Sans" also shows problem.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[Regression] Chinese |uneven emulated Bold/Slant |emulated Bold uneven and no |for subsetted large fonts |longer works |
--- Comment #12 from Hin-Tak Leung htl10@users.sourceforge.net --- Correcting the title after git-bisect. It is not a regression, but a new feature that does not work for some unknown reason on 32-bit cairo.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #13 from Hin-Tak Leung htl10@users.sourceforge.net --- git bisect'ed, and found the first appearance of the "uneven" look is this:
--------- From: Adrian Johnson ajohnson@redneon.com Date: Mon, 22 Nov 2010 22:46:54 +1030 Subject: [PATCH] Use fallback font for synthetic fonts
If the font has been synthesized we can't use the native subsetters as the outlines won't be the same. Instead force the use of the fallback subsetters so the synthesized outlines will used to generate the font. --------- (this was branched off 1.10.0 and leading onto 1.11.2 then onto 1.12.x).
I also realized that the initial description of the problem was wrong: the problem is that new feature of emulated bold (and slant) for large fonts somehow does not work correctly on 32-bit cairo; before that commit, request for bold style for a typeface which does not provide that style was silently dropped, and substituted with the regular style. With that commit, emulated bold is provided by freetype but somehow only works for 64-bit platforms.
The smallest change (which basically partially revert the above commit) is this:
--- a/src/cairo-truetype-subset.c +++ b/src/cairo-truetype-subset.c @@ -159,6 +159,6 @@ _cairo_truetype_font_create (cairo_scaled_font_subset_t *scaled_font_subset, * return CAIRO_INT_STATUS_UNSUPPORTED; */
/* We need to use a fallback font generated from the synthesized outlines. */ - if (backend->is_synthetic && backend->is_synthetic (scaled_font_subset->scaled_font)) + if (0 && (backend->is_synthetic && backend->is_synthetic (scaled_font_subset->scaled_font))) return CAIRO_INT_STATUS_UNSUPPORTED;
The same effect can be achieved by:
--- a/src/cairo-ft-font.c +++ b/src/cairo-ft-font.c @@ -2172,7 +2172,7 @@ _cairo_ft_scaled_glyph_init (void *abstract_font, * synthesize glyphs if requested */ #if HAVE_FT_GLYPHSLOT_EMBOLDEN - if (scaled_font->ft_options.synth_flags & CAIRO_FT_SYNTHESIZE_BOLD) + if (0 && (scaled_font->ft_options.synth_flags & CAIRO_FT_SYNTHESIZE_BOLD)) FT_GlyphSlot_Embolden (glyph); #endif
Anyway, it almost appears as if FT_GlyphSlot_Embolden() does not work correctly for 32-bit platform, which is wierd, since freetype is much more well-tested on 32-bit platforms than 64-bit; so my current thought is that something leading up to FT_GlyphSlot_Embolden (glyph) or some post-processing after is wrong.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #14 from Adrian Johnson ajohnson@redneon.com --- Created attachment 677638 --> https://bugzilla.redhat.com/attachment.cgi?id=677638&action=edit PDF output
This is the PDF output I get from the test case. The 6th character is not bold. In fact it is thinner than the output I get when I set the font weight to normal. This is run on Debian Testing 64-bit using cairo master. I get the same output on Debian Testing 32-bit.
The CairoFont-?-? names are because the font was created using the FreeType outlines instead of subsetting the original font.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #15 from Adrian Johnson ajohnson@redneon.com --- Created attachment 677639 --> https://bugzilla.redhat.com/attachment.cgi?id=677639&action=edit Updated test case to generate PDF, PS, PNG output
This is an updated test case that prints just the single character that is not bold. It generates output in PDF, PS, and PNG.
I compiled with:
gcc -Wall test.c -o test `pkg-config --cflags --libs cairo`
The PNG output is correct. The PDF and PS is not bold.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #16 from Adrian Johnson ajohnson@redneon.com --- Created attachment 677640 --> https://bugzilla.redhat.com/attachment.cgi?id=677640&action=edit broken font
I copied the font from the PS output into a separate the file font-broken.ps. This can be opened in fontforge.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #17 from Adrian Johnson ajohnson@redneon.com --- Created attachment 677641 --> https://bugzilla.redhat.com/attachment.cgi?id=677641&action=edit force fallback fonts
Applying this patch to cairo will force the use of fallback fonts (fonts created from the FreeType outlines instead of using the original font with the unused glyphs stripped out).
I used this patch and ran the test case with the font weight set to CAIRO_FONT_WEIGHT_NORMAL. This allowed me to extract the font from the PS output that was generated using the same code as the font in comment 16.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #18 from Adrian Johnson ajohnson@redneon.com --- Created attachment 677643 --> https://bugzilla.redhat.com/attachment.cgi?id=677643&action=edit good font
This is the font extracted from the PS file generated in comment 17.
You can open both the good and broken font in fontforge and view the characters side by side. The "bold" character has thinner strokes. The horizontal strokes have almost zero width.
It is hard to see how cairo could cause this sort of output. It looks more like a FreeType bug. I'm not sure how to debug this any further without writing some FreeType test code to check the output from FreeType. And that is something I don't have time to do.
Note: the png output from the testcase is using the glyph bitmaps generated by FreeType while the PDF/PS output is using the outlines from FreeType.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #19 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #14) >... This is run on Debian Testing 64-bit using cairo master. I get > the same output on Debian Testing 32-bit.
plot thickens... so 64-bit cairo also suffers occasionally.
> The CairoFont-?-? names are because the font was created using the FreeType > outlines instead of subsetting the original font.
Yes, I see from grep'ing through the code - it was the first difference I noticed from the upgrade... related but somewhat a red-herring.
(In reply to comment #15) >... > The PNG output is correct. The PDF and PS is not bold.
R's X11 display is also somewhat cairo-based - and the display is correct; I think it doesn't affect bitmap devices.
(In reply to comment #16) ... > broken font
One possibility crossed my mind is the font-writing part of cairo (and bad-interaction with freetype emulated fonts). Hence I wrote to Werner (of freetype) of both correctly embolden output & wrong ouput and asked if he could tell how and in what way the glyph data is corrected. fontforge could work now that we know the PS output is also broken, and a "reproducible" way of breaking it...
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #20 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #18) ...
It is hard to see how cairo could cause this sort of output. It looks more like a FreeType bug. I'm not sure how to debug this any further without writing some FreeType test code to check the output from FreeType. And that is something I don't have time to do.
Werner suggested trying to reproduce similar problems if possible with ftview, which can do font effects on display. But I am not hopeful in that since it looks like the problem does not affect bitmap-based output.
Note: the png output from the testcase is using the glyph bitmaps generated by FreeType while the PDF/PS output is using the outlines from FreeType.
I haven't figured out where/how cairo write fonts yet...
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #21 from Adrian Johnson ajohnson@redneon.com --- (In reply to comment #20)
Werner suggested trying to reproduce similar problems if possible with ftview, which can do font effects on display. But I am not hopeful in that since it looks like the problem does not affect bitmap-based output.
I tried ftview but it didn't seem to provide any way to view outlines.
I had another idea. Replace the cairo_show_text with cairo_text_path followed by cairo_fill. This will create paths from the text then fill the paths. This results in correct output.
I haven't figured out where/how cairo write fonts yet...
It has a number of subsetters as well as the ability to create CFF or type 1 fonts. The easiest to understand is cairo-type1-fallback.c which generates fallback fonts for PostScript.
Since cairo_text_path produced the correct output the next idea I had was to try changing the size of the font outlines that cairo-type1-fallback requests. At line 105 the matrix size is set to 1000 since Type 1 fonts have an EM grid size of 1000. I changed this to 500 and the output was smaller but correct. I tried some different values. 800 works. 900 fails. So somewhere between a font size of 800 and 900 FreeType starts producing incorrect output for some glyphs with synthetic bold enabled.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #22 from Hin-Tak Leung htl10@users.sourceforge.net --- BTW, while looking at the cairo code surrounding FT_GlyphSlot_Embolden(), I noted that the types of at least one the parameters passed to FT_* is wrong. load_flags is 'unsigned int' on the freetype side but occasionally just int on the cairo side. That may be harmless but might just be important when doing signed-extended operations like "~ mask" or "<<".
freetype is much more well-tested for 32-bit (and embedded/16-bit(?) environments), and in fact some of the internals are written to do fixed-precision maths with integer operations, assuming floating point maths are too expensive or not available. So it is curious the problem is more serious on 32-bit (and isn't as noticeable on 64-bit platforms).
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #23 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #21)
(In reply to comment #20)
...
Since cairo_text_path produced the correct output the next idea I had was to try changing the size of the font outlines that cairo-type1-fallback requests. At line 105 the matrix size is set to 1000 since Type 1 fonts have an EM grid size of 1000. I changed this to 500 and the output was smaller but correct. I tried some different values. 800 works. 900 fails. So somewhere between a font size of 800 and 900 FreeType starts producing incorrect output for some glyphs with synthetic bold enabled.
That looks like a magic number that can be changed everywhere, for cleanliness, at least:
$ grep -n 1000 src/*fallback* src/cairo-type1-fallback.c:105: cairo_matrix_init_scale (&font_matrix, 1000, -1000); src/cairo-type1-fallback.c:752: type1_subset->widths[i] = (double)font->widths[i]/1000; src/cairo-type1-fallback.c:754: type1_subset->x_min = (double)font->x_min/1000; src/cairo-type1-fallback.c:755: type1_subset->y_min = (double)font->y_min/1000; src/cairo-type1-fallback.c:756: type1_subset->x_max = (double)font->x_max/1000; src/cairo-type1-fallback.c:757: type1_subset->y_max = (double)font->y_max/1000; src/cairo-type1-fallback.c:758: type1_subset->ascent = (double)font->y_max/1000; src/cairo-type1-fallback.c:759: type1_subset->descent = (double)font->y_min/1000;
I Haven't tried, but I think it should work by replacing every "1000" with "800" - since the code basically scale glyph co-ordinates up to x1000 then round to integer. That does not answer why 1000 fails but 800 works though.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #24 from Adrian Johnson ajohnson@redneon.com --- (In reply to comment #23)
I Haven't tried, but I think it should work by replacing every "1000" with "800" - since the code basically scale glyph co-ordinates up to x1000 then round to integer. That does not answer why 1000 fails but 800 works though.
I compiled the latest freetype (2.4.11) and the test case now works correctly.
There seems to have been a few fixes to the emboldening code since 2.4.10: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/src/base/ftoutln...
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #25 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #24)
(In reply to comment #23)
I Haven't tried, but I think it should work by replacing every "1000" with "800" - since the code basically scale glyph co-ordinates up to x1000 then round to integer. That does not answer why 1000 fails but 800 works though.
I compiled the latest freetype (2.4.11) and the test case now works correctly.
There seems to have been a few fixes to the emboldening code since 2.4.10: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/src/base/ftoutln. c
upgrading to freetype 2.4.11 was the first thing I tried as well - it got worse (some of the glyph has gone "reverse video"!). I'll upload that to show you.
The 64-bit version continue to work well, strangely.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #26 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 678118 --> https://bugzilla.redhat.com/attachment.cgi?id=678118&action=edit from the small test program in comment 10, 32-bit, freetype 2.4.11
from the small test program in comment 10, 32-bit, freetype 2.4.11
It has gotten worse - two of the glyphs now looks "reversed".
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #27 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 678121 --> https://bugzilla.redhat.com/attachment.cgi?id=678121&action=edit from the small test program in comment 10, 64-bit, freetype 2.4.11
from the small test program in comment 10, 64-bit, freetype 2.4.11,
just to make sure that 64-bit continues to work correctly...
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #28 from Adrian Johnson ajohnson@redneon.com --- Looks like it is definitely a freetype problem. I suggest filing a freetype bug.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #29 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #24) ...
I compiled the latest freetype (2.4.11) and the test case now works correctly.
...
It has gone worse for me (see comment 26) - it is probably some subtle issue that depends on compiler options, etc.
FWIW, I grab the binary first: http://koji.fedoraproject.org/koji/buildinfo?buildID=375798 then do an rpmbuild --rebuild (with or without --target=i686).
You don't have to install them but it would be interesting say, if you do "rpm2cpio | cpio --extract -m -d ", then do LD_LIBRARY_PATH, if you can get a broken pdf :-).
Is there a debian binary of 32-bit freetype 2.4.11 I can download from a public place?
(In reply to comment #28)
Looks like it is definitely a freetype problem. I suggest filing a freetype bug.
I would probably say so as well, except (1) so far we haven't found a way of doing it without the higher-level libraries of cairo, fontconfig, (I thought about trying the original R sample under windows R; that would possibly be without fontconfig or freetype or both)... (2) freetype is much more well-tested on 32-bit than 64-bit - in fact Werner mentioned that he does not have a 64-bit machine!
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #30 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #28)
Looks like it is definitely a freetype problem. I suggest filing a freetype bug.
I tried LD_LIBRARY_PATH both http://ftp.uk.debian.org/debian/pool/main/f/freetype/libfreetype6_2.4.9-1.1_... http://ftp.uk.debian.org/debian/pool/main/f/freetype/libfreetype6_2.4.9-1.1_... then http://koji.fedoraproject.org/koji/buildinfo?buildID=310621
and indeed I got the 6th glyph and only the 6th glypth wrong in all 4 versions. then I just did
git checkout VER-2-4-11 ./autogen.sh CFLAGS=-m32 LDFLAGS=-m32 ./configure
and LD_LIB... still got the partially reversed-video look like I had with rpm-driven built 32-bit freetype.
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?
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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #31 from Adrian Johnson ajohnson@redneon.com --- (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.
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?
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.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |behdad@fedoraproject.org, | |kevin@tigcc.ticalc.org, | |mkasik@redhat.com Component|cairo |freetype
--- Comment #33 from Hin-Tak Leung htl10@users.sourceforge.net --- Okay, I think I have got a handle on it... reassigning to freetype & I'll take it up with Werner... possibly will result in a new freetype version.
What happened is this: newer cairo started to use a feature in freetype which is still being changed (rather a lot!). older cairo just doesn't do emboldening so isn't afffected by freetype's changes; 5 commits in reverse-order from a freetype developer who isn't Werner (and therefore my faith about 32-bit correctness doesn't apply):
commit 0690d3d7b59ccb54a9938ff99c8621350780fc6e commit dd5718c7d67a5b6d7dfc2546c9bda734b246142e commit 48ce226ae3c2ccbe3230417d118ada4fea8508e3 commit 2bdd0949762acea68b4335f7c73ae14c5a34a2cc commit f875fc71179b1e742d6f782b8c99b0cc031c9467
The 4th make 64-bit freetype work well but simultaneously make 32-bit freetype dramatically poor (this happened after 2.4.9). The first 3 have little or no effect on 64-bit build, but introduces various overflow problems. commit 1 "Fix integer overflows in dd5718c7d67a" in commit 2, but does not fully, so the two of them introduced the reverse-video look I see from 2.4.10 to 2.4.11.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #34 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 683564 --> https://bugzilla.redhat.com/attachment.cgi?id=683564&action=edit part of a fix
Here is a patch from Alexei Podtelezhnikov (the author of the 4 commits in the last comment) which fixes some of the problems. There will be another one.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #683564|0 |1 is obsolete| |
--- Comment #35 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 689537 --> https://bugzilla.redhat.com/attachment.cgi?id=689537&action=edit back ported fix to 2.4.11
backported full fix to 2.4.11 (obsoleting the last attachment).
Deal with overflows and underflows.
The equivalent were committed to freetype head as
commit 610ee58e07090ead529849b2a454bb6c503b4995 [base] Fix broken emboldening at small sizes. commit da11e5e7647b668dee46fd0418ea5ecbc33ae3b2 [base] Fix integer overflow. commit e1a2ac1900f2f16ec48fb4840a6b7965a8373c2b [base] Fix integer overflow.
and part of commit 869fb8c49ddf292d6daf4826172a308973d3e11f [base] Split out MSB function.
Thanks Alexei and Werner (and me for part of da11e5e7647b668dee46fd0418ea5ecbc33ae3b2) for providing the fixes.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #36 from Hin-Tak Leung htl10@users.sourceforge.net --- Please close when either 2.4.12 or a patched 2.4.11 with the attachement in the last comment is released.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Kevin Kofler kevin@tigcc.ticalc.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|otte@redhat.com |mkasik@redhat.com
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Kevin Kofler kevin@tigcc.ticalc.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mkasik@redhat.com | |)
--- Comment #37 from Kevin Kofler kevin@tigcc.ticalc.org --- Can we please have this fix backported to the Fedora 18 freetype?
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Marek Kašík mkasik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mkasik@redhat.com | |) |
--- Comment #38 from Marek Kašík mkasik@redhat.com --- Hi, I'm going to look at this today.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #39 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #38)
Hi, I'm going to look at this today.
Good luck. I would suggest rolling the patch in comment 35 into the f19 2.4.11 rpm. (this is actually what I am running and why/how the patch was/is tested). If you insist on patching the older 2.4.10 or 2.4.9, you'll need to look at the 5 commits listed in comment 33.
To test that you have done so correctly, use *both* the test program in comment 10, and the embolden mode in ftview (press "2"), and under both 32-bit and 64-bit. (the pdf backend of cairo checks one thing, the ftview's embolden mode checks another, and some of the relevant code behaves differently under 32-bit vs 64-bit mode). 'WenQuanYi Zen Hei' (wqy-zenhei-fonts) seems to be worst affected font, but you should see improvements with "Droid Sans" and others.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #40 from Marek Kašík mkasik@redhat.com --- I'll continue on this after weekend, I have to perform some tests yet.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #41 from Marek Kašík mkasik@redhat.com --- (In reply to comment #39)
(In reply to comment #38) To test that you have done so correctly, use *both* the test program in comment 10, and the embolden mode in ftview (press "2"), and under both 32-bit and 64-bit. (the pdf backend of cairo checks one thing, the ftview's embolden mode checks another, and some of the relevant code behaves differently under 32-bit vs 64-bit mode). 'WenQuanYi Zen Hei' (wqy-zenhei-fonts) seems to be worst affected font, but you should see improvements with "Droid Sans" and others.
Hi,
could you point me to specific glyph index in a specific font which shows the problem in ftview in the embolden mode? I can not find a glyph showing the problem there.
Marek
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #42 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #41)
Hi,
could you point me to specific glyph index in a specific font which shows the problem in ftview in the embolden mode? I can not find a glyph showing the problem there.
Marek
Even just the bottom page of glyph indices of 'WenQuanYi Zen Hei' (wqy-zenhei-fonts) are quite bad.
The 4 glyphs "因用图圖" (utf8, hopes it shows) are quite bad in 2.4.11 and shows a reversed look (some outlines wound the wrong way due to overflow/underflow) via the cairo pdf backend. File name "【普羅米修斯】打造機器人--"大衛"-0m_gMnzG8w0.mp4" since it is an mp4 file, and "ls --color=auto" is on so embolden in gnome termnial, and can cause gnome-terminal to go blank. Also in the course of testing, various fontconfig-dependent gtk applications - mozilla seamonkey, go blank when trying to to render web pages with embolden texts.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #43 from Marek Kašík mkasik@redhat.com --- (In reply to comment #42)
(In reply to comment #41)
Hi,
could you point me to specific glyph index in a specific font which shows the problem in ftview in the embolden mode? I can not find a glyph showing the problem there.
Marek
Even just the bottom page of glyph indices of 'WenQuanYi Zen Hei' (wqy-zenhei-fonts) are quite bad.
What is the starting index of those glyphs in ftview? Could you make a screenshot of the page?
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #44 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to comment #43)
What is the starting index of those glyphs in ftview? Could you make a screenshot of the page?
ftdump -v provides glyph indices to unicode mapping... I have some "obviously" broken" screenshots of ftview while testing intemediate versions of the fix but don't have the corresponding "good" one at the moment. Also a pair of broken and good screenshot of gnome-terminal ("ls --color=auto" listings of files).
Just a vaguely related note for testing: it seems that gnome-terminal and seamonkey - and possibly other gtk-based applications - do some sort of double-buffering so when some glyphs fail in some way from underflow within freetype, the whole window stays blank. This is different from ftview which shows very interesting results...
The last of the fix is http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=d56e544d6... but somewhat irrelevant as far as backport is concerned, since it is just a comment explaining a non-obvious point to prevent future rewrites breaking this code.
I'll attach some screenshots when I find the time.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #45 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 711682 --> https://bugzilla.redhat.com/attachment.cgi?id=711682&action=edit screenshot of broken gnome terminal, vs correct one.
screenshot of broken gnome terminal, vs correct one.
These two (gimp'ed to get them side-by-side but otherwise unmod'ed) were among some of the e-mails with the freetype people while testing changes. I think the left hand-side was what prompted the last or the 2nd last of the commits in comment 35. i.e. if you don't apply the whole series but skip the last or possibly the last two you can get this look with gnome terminal.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #46 from Hin-Tak Leung htl10@users.sourceforge.net --- Created attachment 711683 --> https://bugzilla.redhat.com/attachment.cgi?id=711683&action=edit two broken ftview - just different requested font size
screenshots of two brokenness with ftview - just different requested font size
These screenshots were what led to the prototype of da11e5e7647b668dee46fd0418ea5ecbc33ae3b2 being revised to its final committed form, and the later accompanying comment commit d56e544d653b09c657911629557ffc5277a503e3 .
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #47 from Hin-Tak Leung htl10@users.sourceforge.net --- The bottom line of the issue is that cairo used freetype in an unanticipated way - until this report -, and the anticipated usage - i.e. usage exercised by ft-demos (ftview/ftdump) is rarely broken.
But then cairo is used by fontconfig and in turn used by gtk so the only sensible way to test fixes is to put freetype out system-wise and see what breaks. gnome terminal broken was unexpected - OTOH, the screenshot shown was the "nicer" brokenness: the nastier brokenness - my first hand experiences - was when the whole window of the web-browser or that of the terminal stopped refreshing and went blank just because either of them had trouble showing a small portion of its window, which involves some texts in bold.
usage under ftview was only broken in the middle of trying to fix usage under cairo.
I am just think what is a good test/validation plan - generally this involves confirming reported issues are fixed without causing serious regressions; "confirming reported issues are fixed" is easy, but considering how widely cairo and freetype are used, and that the freetype's demos (ftview in particular) does not exercise the part of freetype in the way cairo uses it, trying to confirm proposed patch does not cause regressions on dependent software etc - which in this case means any and every GUI-based application which have some texts displayed - is hard.
(FWIW, I have the patched freetype 2.4.11 system-wide, both 32-bit & 64-bit, just to make sure nothing breaks)
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |MODIFIED
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #48 from Fedora Update System updates@fedoraproject.org --- freetype-2.4.10-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/freetype-2.4.10-4.fc18
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #49 from Marek Kašík mkasik@redhat.com --- Hi,
thank you for the info. I've committed the set of backported patches to F18, F19 and rawhide.
Regards
Marek
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #50 from Kevin Kofler kevin@tigcc.ticalc.org --- Thanks!
I also applied your backported patches in freetype-freeworld-2.4.11-2.fc20 (not built yet because the build failed, the RPM Fusion builder is hitting checksum errors in the Rawhide repo on dl.fedoraproject.org), freetype-freeworld-2.4.11-2.fc19 and freetype-freeworld-2.4.10-3.fc18.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #51 from Fedora Update System updates@fedoraproject.org --- Package freetype-2.4.10-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing freetype-2.4.10-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4093/freetype-2.4.10-4.f... then log in and leave karma (feedback).
https://bugzilla.redhat.com/show_bug.cgi?id=891457
--- Comment #52 from Fedora End Of Life endoflife@fedoraproject.org --- This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
https://bugzilla.redhat.com/show_bug.cgi?id=891457
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Fixed In Version| |freetype-2.4.10-4.fc18 Resolution|--- |ERRATA Last Closed| |2014-01-15 01:30:42
i18n-bugs@lists.fedoraproject.org