Description of problem: There is a PDF rendering problem in Chromium, caused by a FreeType bug. See https://bugs.chromium.org/p/chromium/issues/detail?id=696356 and http://savannah.nongnu.org/bugs/?50470 The upstream patch fixing the bug is here: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=bcc74f4dafee25ea89f1d3144646cba7e30f9908 Please consider including the upstream patch in Fedora until it is included in a release.
Hi, I've just tested the patch but it doesn't fix the issue. I'll look at it in more detail.
I'm sorry, I was testing wrong file. The patch fixes the issue. I'll prepare an update with it.
freetype-2.7.1-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-43db8d2e92
freetype-2.6.5-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a14aa819ff
freetype-2.6.5-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-a14aa819ff
freetype-2.7.1-3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-43db8d2e92
freetype-freeworld-2.7.1-3.fc27, freetype-freeworld-2.7.1-3.fc26, freetype-freeworld-2.6.5-3.fc25 building with this fix at the usual well-known third-party repository.
Looking at the original commit that supposedly broke this: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34e66052ccfee7996e5468f30d4bd5a72 And the reversal: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=bcc74f4dafee25ea89f1d3144646cba7e30f9908 The latter appears to do extra stuff. Could that be the reason why F25 package screwed up font rendering?
Created attachment 1268962 [details] before the update This update messes with font rendering in a weird way. It causes fonts to look really weird. To reproduce: install the update, close gnome-terminal, open the terminal again. (note: in this pic you can see I have the i686 version with the update, but it doesn't matter because gnome-terminal is x86_64)
Created attachment 1268963 [details] after the update You can see fonts are squished in the -3 version compared to the -2 version.
Elad: can you comment on the upstream bug report? https://savannah.nongnu.org/bugs/?50470
(In reply to Elad Alfassa from comment #10) > Created attachment 1268963 [details] > after the update > > You can see fonts are squished in the -3 version compared to the -2 version. Thank you for the screenshots. I have few questions for you. Which font is it? Which hinting do you use?
This is the default monospace font that gnome-terminal uses, I don't know its name. As for hinting setting, I'm using 'slight'
Thank you for the information, I am able to reproduce it now.
(In reply to Elad Alfassa from comment #13) > This is the default monospace font that gnome-terminal uses, I don't know > its name. As for hinting setting, I'm using 'slight' I'm seeing the same issue [with the monospace font & 'slight' hinting]. For now - reverted to freetype-2.7.1-2.fc26.x86_64
Fonts and bars in conky are also affected by the update to freetype-2.6.5-4.fc25.
Probably need to revert this until upstream figures out what to do.
So, how are you going to proceed here? I see the F25 and F26 updates have been unpushed (I also got my freetype-freeworld RPM Fusion ones untagged), but Rawhide still has the patch. Are you going to revert Rawhide too? Are you going to try a different patch?
(In reply to Kevin Kofler from comment #18) > So, how are you going to proceed here? I see the F25 and F26 updates have > been unpushed (I also got my freetype-freeworld RPM Fusion ones untagged), > but Rawhide still has the patch. Are you going to revert Rawhide too? Are > you going to try a different patch? I'll revert it everywhere for now and will wait for upstream's decision.
According to https://savannah.nongnu.org/bugs/?50470#comment19 the change triggers an edge condition in the autohinter, but one that brings it closer in line with the native hinter. Since it is a rendering change (but seems to be a reasonable one), should this patch go into F26 and Rawhide but not be backported?
(In reply to Adam Goode from comment #20) > According to https://savannah.nongnu.org/bugs/?50470#comment19 the change > triggers an edge condition in the autohinter, but one that brings it closer > in line with the native hinter. > > Since it is a rendering change (but seems to be a reasonable one), should > this patch go into F26 and Rawhide but not be backported? wrt F26 - I prefer the current rendering that is in freetype-2.7.1-2 [the changed rendering looks bad for reading]. It would be great if the current rendering can be preserved in some manner - perhaps with a different hint - say 'vertical' or some other name..
(In reply to Adam Goode from comment #20) > According to https://savannah.nongnu.org/bugs/?50470#comment19 the change > triggers an edge condition in the autohinter, but one that brings it closer > in line with the native hinter. > > Since it is a rendering change (but seems to be a reasonable one), should > this patch go into F26 and Rawhide but not be backported? The patch, as was delivered in F25, changed the size of fonts significantly. Windows changed size a result and most fonts rendered too tall. So, no - it doesn't bring it closer to rendering without autohinter. That may be the theory, but practice was different.
(In reply to Bojan Smojver from comment #22) > The patch, as was delivered in F25, changed the size of fonts significantly. > Windows changed size a result and most fonts rendered too tall. Too tall? Did you mean too short? If fonts are rendering taller now, then that is another problem that's not yet been investigated. Either way, I will comment on the upstream bug and see if there is some autohinter tweak that could be made to keep this metric from changing.
(In reply to Adam Goode from comment #23) > Too tall? Did you mean too short? If fonts are rendering taller now, then > that is another problem that's not yet been investigated. My Gnome terminal windows have all gone taller and less wide as a result of the change. I use Liberation Mono Regular font at 8 points, with autohinting turned on (looks better on my screens). There are other changes as well in Evo, Pidgin etc. Essentially, the metrics of fonts changed significantly, which is a visual regression. If I turn autohinter off, I do not get such changes at all.
(In reply to Bojan Smojver from comment #24) > My Gnome terminal windows have all gone taller and less wide as a result of > the change. I use Liberation Mono Regular font at 8 points, with autohinting > turned on (looks better on my screens). What is the DPI setting for your screen so that I can investigate? I do see narrower glyphs assuming DPI=96 but the x-height (lowercase letters) is quite consistent with the native hinter. The DPI setting is important because this is when the point-to-ppem rounding used to occur.
(In reply to Alexei Podtelezhnikov from comment #25) > What is the DPI setting for your screen so that I can investigate? xrdb -query returns 96 on both my VM (Xvnc used behind xrdp) and T450s (wayland).
Here is what happens. At 96 dpi, 8 points corresponds to 10.6666 ppem. This used to be rounded up to 11 as if you requested 8.25 points. Now the rounding is not happening and FreeType respectfully hints and delivers results that correspond to 8 points better. Since hinting is discrete this may dramatically shrink each letter by 1 pixel, which adds up in monospace terminal window. Freetype does not do anything wrong, does it?
(In reply to Alexei Podtelezhnikov from comment #27) > Freetype does not do anything wrong, does it? Well, it displays everything very, very differently than before. Far more squashed etc. Makes my terminals way less legible. See attached old-algorithm.png and new-algorithm.png.
Created attachment 1272177 [details] Before the patch, Liberation Mono Regular 8 pt
Created attachment 1272178 [details] After the patch, Liberation Mono Regular 8 pt
(In reply to Bojan Smojver from comment #28) > (In reply to Alexei Podtelezhnikov from comment #27) > > > Freetype does not do anything wrong, does it? > > Well, it displays everything very, very differently than before. Far more > squashed etc. Makes my terminals way less legible. See attached > old-algorithm.png and new-algorithm.png. Well, may I suggest you increase the size to 9 points if your desktop environment is so inflexible to let you choose 8.25 points? I am only partly facetious. I do not see anything wrong. Different yes, wrong no.
(In reply to Alexei Podtelezhnikov from comment #31) > Well, may I suggest you increase the size to 9 points if your desktop > environment is so inflexible to let you choose 8.25 points? I am only partly > facetious. I do not see anything wrong. Different yes, wrong no. Tried that. Even tried strange stuff like 8.15 etc. However, because the geometry is different, the usable space on the desktop changes. Instead of being able to fit 9 terminal windows, I can only fit 6 now. Ergo, less usable for me. Also, mutter obviously places those things differently, so I have to fiddle with windows after I open them etc. Mildly annoying. Look, in the end, I'm just pointing out what happened. If I need to change fonts I use for my terminals (again), I'll do it. Another several days of fiddling to find a usable combination.
(In reply to Alexei Podtelezhnikov from comment #27) > > Freetype does not do anything wrong, does it? My usage is 'gnome-terminal' with default monospace font set to 'monospace regular' 11 The display is '1600x900' with '96' dpi with 'slight' hint Perhaps the font as currently rendered is buggy - but its more readable then the 'bug fixed' rendering. Note: increasing the font size is not the fix (or workaround) for me - the vertical to horizontal proportion is different between the 'current' and 'fixed' rendering - and this makes a difference in readability. It would be great if there is a way (perhaps add a new hint) to preserves the current rendering ratio for my usage. [and also have this bugfix wrt pdf rendering] My alternative would to freeze freetype to currently working [wrt rendering] 2.7.1-2.fc26 version. Or switch to konsole - but having gotten used to gnome-terminal - I'm trying to avoid that switch [Its not clear to me why the freetype change is not affecting konsole - and if it will also change behaviour at some future point] I tried switching to other mono fonts - but they were less readable than the current font (for me)
Created attachment 1272202 [details] After the patch, Liberation Mono Regular 8.25 pt
(In reply to Satish Balay from comment #33) > Note: increasing the font size is not the fix (or workaround) for me - the > vertical to horizontal proportion is different between the 'current' and > 'fixed' rendering - and this makes a difference in readability. I was mistaken here. Using 'monospace regular 11.3' [with patched freetype version] looks same as unpatched 'monospace regular 11' on gnome-terminal - so that's good enough for me to switch.
(In reply to Bojan Smojver from comment #34) > Created attachment 1272202 [details] > After the patch, Liberation Mono Regular 8.25 pt Thank you for the images. So the width at 8.25 pt looks as before but the height is different. This is strange because ftview keeps the same line spacing for both 8 pt and 8.25 pt based on face->size->metrics.height = 12.0 pixels. It should not have been rounded like this, but, regardless, gnome-terminal definitely uses something else to figure out the line spacing.
The unrounded height is 12.47 pixels for 8.25 pt and 12.09 pixels for 8 pt. gnome-terminal likely relies on something else.
(In reply to Alexei Podtelezhnikov from comment #37) > The unrounded height is 12.47 pixels for 8.25 pt and 12.09 pixels for 8 pt. > gnome-terminal likely relies on something else. If I set the font size to 8.25 with the old freetype, the size of the terminal does not change at all when compared to 8 points. So, I'm guessing both get rounded down to 12. The first time I see a change is if I set the size to 8.7 (which Gnome terminal sets as 8.699). The spacing between lines is still a lot smaller than with the new freetype. Just FYI.
I don't know the code well, but I suspect it's something in font_info_measure_font at https://github.com/GNOME/vte/blob/master/src/vtedraw.cc#L382 Also, it looks like this particular issue comes up from time to time. See https://bugzilla.gnome.org/show_bug.cgi?id=738781
Is anything affected besides gnome-terminal (vte) ? If vte is the only thing, then I would recommend moving forward with this cherrypick, since it does fix a nasty rendering issue with printing from Chromium. It is looking like the vte solution is to implement the request in https://bugzilla.gnome.org/show_bug.cgi?id=738781. I will comment on that bug and point them here.
(In reply to Adam Goode from comment #40) > Is anything affected besides gnome-terminal (vte) ? There are some changes to other fonts, but they are not nearly as prominent. So, I'll relent - push it and let's see what happens. The search for another set of terminal fonts starts now. :-)
Here: https://github.com/GNOME/vte/blob/master/src/vtedraw.cc#L391 within the howmany(), a ceil is happening. Changing that to round will probably get you what you want.
If someone files a bug against vte in gnome bugzilla, I can fix this.
(In reply to Behdad Esfahbod from comment #43) > If someone files a bug against vte in gnome bugzilla, I can fix this. https://bugzilla.redhat.com/show_bug.cgi?id=1443257
(In reply to Behdad Esfahbod from comment #43) > If someone files a bug against vte in gnome bugzilla, I can fix this. I closed the redhat bug and opened this one: https://bugzilla.gnome.org/show_bug.cgi?id=781479 Thanks, Behdad!
(In reply to Bojan Smojver from comment #41) > There are some changes to other fonts, but they are not nearly as prominent. > So, I'll relent - push it and let's see what happens. Would be great if vte and freetype updates could be pushed together, to avoid a period of breakage and enable proper testing.
Unfortunately I was wrong. Following up here: https://bugzilla.gnome.org/show_bug.cgi?id=781479
Different does not mean wrong (repeat 100 times). Gnome-terminal uses pango. Can you confirm that line spacing changes in other applications too. Can we establish the custody line for the metric in question? If this metric comes from FreeType, it should have been scaled properly using 8.25 points as a workaround. It is possible that FreeType misses something. If this metric is cooked ad hoc inside pango or vte, then and only then you should fix the issue there.
I can reproduce the line spacing differences with ftdiff: ftdiff -s 8 -r 96 /usr/share/fonts/dejavu/DejaVuSansMono.ttf So I don't think pango nor vte are doing anything odd. The font really does shift around a bit at this small size with these edge rounding cases. (And it does look better with the newer freetype to my eye.) The only thing is to give gnome-terminal a spacing parameter so that folks can adjust this as desired. https://bugzilla.gnome.org/show_bug.cgi?id=738781 Not sure if you want to block this bug on any potential gnome-terminal/vte enhancements. Thanks to everyone for all the thorough investigations.
Actually it is not quite a direct reproduction. I can get ftdiff to show some differences, but they don't always match pango's differences. Still, the fact that ftdiff shows similar kinds of differences to pange makes me feel better.
Created attachment 1272843 [details] Before patch: ftdiff -s 8 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf
Created attachment 1272844 [details] After patch: ftdiff -s 8 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf
Created attachment 1272845 [details] After patch: ftdiff -s 8.25 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf
Created attachment 1272846 [details] After patch: ftdiff -s 8.3 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf
If you compare 8 old with 8.25 new for Liberation Mono (which are supposed to be the same, according to the discussion above), you'll notice that they are not quite the same. 8.25 new is more vertically stretched. Not as much as in the terminal, I think, but still. Also, not quite sure whether ftdiff understands 8.25 or whether that's really 8.2 only. In which case, 8.3 may also be relevant to some degree.
(In reply to Bojan Smojver from comment #55) > If you compare 8 old with 8.25 new for Liberation Mono (which are supposed > to be the same, according to the discussion above), you'll notice that they > are not quite the same. I aligned old "8" and new "8.25" side by side. They have identical line spacing. Ftdiff relies on face->size->metrics.height that is properly scaled.
(In reply to Bojan Smojver from comment #55) > If you compare 8 old with 8.25 new for Liberation Mono (which are supposed > to be the same, according to the discussion above), you'll notice that they > are not quite the same. When I compare 8-old and 8.25-new images (from above) - both fonts [and spacing] look exactly the same to me. The difference I see is the spacing between the 'bold' font used by the 'header' - and the regular font text. So perhaps its an issue with the bold font used here? BTW: I used 'gthumb' in full screen mode to compare the above images. Wrt my usage of 'monospace regular 11' with gnome-terminal - I find the following 3 cases are exactly the same: * old monospace regular 11 * old monospace regular 11.3 * new monospace regular 11.3
(In reply to Satish Balay from comment #57) > The difference I see is the spacing between the 'bold' font used by the > 'header' - and the regular font text. Yeah, you're both quite right. That's why the bulk of the text moves from one image to the next.
Folks, please give me a few days to finish a fix. I'm going to restore the old behaviour more or less (but still correcting the metrics issue), while at the same time introducing a new auto-hinting mode that really doesn't adjust the advance widths. It's a non-trivial issue – the main problem is that the hinting mode selection happens very late (while calling `FT_Load_Glyph')...
(In reply to Werner Lemberg from comment #59) > Folks, please give me a few days to finish a fix. I'm going to restore the > old behaviour more or less (but still correcting the metrics issue), while > at the same time introducing a new auto-hinting mode that really doesn't > adjust the advance widths. > > It's a non-trivial issue – the main problem is that the hinting mode > selection happens very late (while calling `FT_Load_Glyph')... Thank you kindly for working on this! There is absolutely no rush here.
Please read http://lists.nongnu.org/archive/html/freetype-devel/2017-04/msg00042.html It should explain what has been changed, and what can be done.
FreeType 2.8 should fix these issues.
(In reply to Adam Goode from comment #62) > FreeType 2.8 should fix these issues. So, just to be clear, does that mean font rendering (i.e. specifically various sizes) in the cases reported in this bug will look at same in F27 as it currently does in F26/25/24 etc.?
Not sure, you should try out F27 and see.
(In reply to Bojan Smojver from comment #63) > (In reply to Adam Goode from comment #62) > > FreeType 2.8 should fix these issues. > > So, just to be clear, does that mean font rendering (i.e. specifically > various sizes) in the cases reported in this bug will look at same in F27 as > it currently does in F26/25/24 etc.? I just tried rebuilding 2.8 rpm on F26 $ rpm -q freetype freetype-2.8-1.fc26.x86_64 freetype-2.8-1.fc26.i686 I have to change my (monospace regular) font size from 11 to 11.25 (or 11.3) for it to match F26/25/24 font - [I had to do the same change with 2.7.1-3]. The font looks squished vertically with my previous setting of size 11 [as it did with 2.7.1-3]
Hi, since I want to keep freetype in Fedora on the default version as much as possible, I did not activated the AF_CONFIG_OPTION_TT_SIZE_METRICS option in 2.8. So fonts in rawhide will look like the ones from 2.7.1-3 update. I also tried to look at whether I could backport this option (or its part) to fix the state after application of the commit mentioned in the description of this bug to F24, F25 and F26. But it is a lot of code so there is high chance of introducing of a regression and hence I won't backport this and leave it this way. Regarding the Chromium case, it seems that people around Chromium are discussing about bundling of their own freetype which could solve the issue even in F24, F25 and F26 depending on whether and when they will do that (https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-packagers/xhmgu-1Vcok).
The QtWebEngine package, and maybe also the Fedora Chromium package, would likely still be built against the system FreeType.
(In reply to Marek Kašík from comment #66) > since I want to keep freetype in Fedora on the default version as much as > possible, I did not activated the AF_CONFIG_OPTION_TT_SIZE_METRICS option in > 2.8. So fonts in rawhide will look like the ones from 2.7.1-3 update. OK, thanks. I'm guessing this will be documented in F27 release notes, for all the folks that never bumped into this bug report.
Marek: have you considered upgrading F24/F25/F26 to FreeType 2.8 and setting AF_CONFIG_OPTION_TT_SIZE_METRICS only for those releases? I'm guessing the risk of regression is too high, though it would probably be safer than attempting cherrypicks.