https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Bug ID: 1437999 Summary: FreeType bug causes Chromium misrendering of PDF Product: Fedora Version: 25 Component: freetype Assignee: mkasik@redhat.com Reporter: adam@spicenitz.org QA Contact: extras-qa@fedoraproject.org CC: behdad@fedoraproject.org, fonts-bugs@lists.fedoraproject.org, kevin@tigcc.ticalc.org, mkasik@redhat.com
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=bcc74f4da...
Please consider including the upstream patch in Fedora until it is included in a release.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #1 from Marek Kašík mkasik@redhat.com --- Hi,
I've just tested the patch but it doesn't fix the issue. I'll look at it in more detail.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #2 from Marek Kašík mkasik@redhat.com --- I'm sorry, I was testing wrong file. The patch fixes the issue. I'll prepare an update with it.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #3 from Fedora Update System updates@fedoraproject.org --- freetype-2.7.1-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-43db8d2e92
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #4 from Fedora Update System updates@fedoraproject.org --- freetype-2.6.5-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a14aa819ff
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #5 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #6 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #7 from Kevin Kofler kevin@tigcc.ticalc.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Bojan Smojver bojan@rexursive.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bojan@rexursive.com
--- Comment #8 from Bojan Smojver bojan@rexursive.com --- Looking at the original commit that supposedly broke this:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34...
And the reversal:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=bcc74f4da...
The latter appears to do extra stuff. Could that be the reason why F25 package screwed up font rendering?
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Elad Alfassa elad@eladalfassa.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |elad@eladalfassa.com
--- Comment #9 from Elad Alfassa elad@eladalfassa.com --- Created attachment 1268962 --> https://bugzilla.redhat.com/attachment.cgi?id=1268962&action=edit 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)
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #10 from Elad Alfassa elad@eladalfassa.com --- Created attachment 1268963 --> https://bugzilla.redhat.com/attachment.cgi?id=1268963&action=edit after the update
You can see fonts are squished in the -3 version compared to the -2 version.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #11 from Adam Goode adam@spicenitz.org --- Elad: can you comment on the upstream bug report? https://savannah.nongnu.org/bugs/?50470
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #12 from Marek Kašík mkasik@redhat.com --- (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?
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #13 from Elad Alfassa elad@eladalfassa.com --- This is the default monospace font that gnome-terminal uses, I don't know its name. As for hinting setting, I'm using 'slight'
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #14 from Marek Kašík mkasik@redhat.com --- Thank you for the information, I am able to reproduce it now.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Satish Balay balay@fastmail.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |balay@fastmail.fm
--- Comment #15 from Satish Balay balay@fastmail.fm ---
(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
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Alexander Ploumistos alex.ploumistos@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alex.ploumistos@gmail.com
--- Comment #16 from Alexander Ploumistos alex.ploumistos@gmail.com --- Fonts and bars in conky are also affected by the update to freetype-2.6.5-4.fc25.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #17 from Adam Goode adam@spicenitz.org --- Probably need to revert this until upstream figures out what to do.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Kevin Kofler kevin@tigcc.ticalc.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |NEW
--- Comment #18 from Kevin Kofler kevin@tigcc.ticalc.org --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #19 from Marek Kašík mkasik@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #20 from Adam Goode adam@spicenitz.org --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #21 from Satish Balay balay@fastmail.fm --- (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..
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #22 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #23 from Adam Goode adam@spicenitz.org --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #24 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Alexei Podtelezhnikov apodtele@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |apodtele@gmail.com
--- Comment #25 from Alexei Podtelezhnikov apodtele@gmail.com ---
(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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #26 from Bojan Smojver bojan@rexursive.com --- (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).
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #27 from Alexei Podtelezhnikov apodtele@gmail.com --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #28 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #29 from Bojan Smojver bojan@rexursive.com --- Created attachment 1272177 --> https://bugzilla.redhat.com/attachment.cgi?id=1272177&action=edit Before the patch, Liberation Mono Regular 8 pt
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #30 from Bojan Smojver bojan@rexursive.com --- Created attachment 1272178 --> https://bugzilla.redhat.com/attachment.cgi?id=1272178&action=edit After the patch, Liberation Mono Regular 8 pt
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #31 from Alexei Podtelezhnikov apodtele@gmail.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #32 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #33 from Satish Balay balay@fastmail.fm --- (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)
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #34 from Bojan Smojver bojan@rexursive.com --- Created attachment 1272202 --> https://bugzilla.redhat.com/attachment.cgi?id=1272202&action=edit After the patch, Liberation Mono Regular 8.25 pt
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #35 from Satish Balay balay@fastmail.fm --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #36 from Alexei Podtelezhnikov apodtele@gmail.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #37 from Alexei Podtelezhnikov apodtele@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #38 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #39 from Adam Goode adam@spicenitz.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #40 from Adam Goode adam@spicenitz.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #41 from Bojan Smojver bojan@rexursive.com --- (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. :-)
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #42 from Behdad Esfahbod behdad@fedoraproject.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #43 from Behdad Esfahbod behdad@fedoraproject.org --- If someone files a bug against vte in gnome bugzilla, I can fix this.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #44 from Bojan Smojver bojan@rexursive.com --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #45 from Adam Goode adam@spicenitz.org --- (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!
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #46 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #47 from Behdad Esfahbod behdad@fedoraproject.org --- Unfortunately I was wrong. Following up here: https://bugzilla.gnome.org/show_bug.cgi?id=781479
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #48 from Alexei Podtelezhnikov apodtele@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #49 from Adam Goode adam@spicenitz.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #50 from Adam Goode adam@spicenitz.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #51 from Bojan Smojver bojan@rexursive.com --- Created attachment 1272843 --> https://bugzilla.redhat.com/attachment.cgi?id=1272843&action=edit Before patch: ftdiff -s 8 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #52 from Bojan Smojver bojan@rexursive.com --- Created attachment 1272844 --> https://bugzilla.redhat.com/attachment.cgi?id=1272844&action=edit After patch: ftdiff -s 8 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #53 from Bojan Smojver bojan@rexursive.com --- Created attachment 1272845 --> https://bugzilla.redhat.com/attachment.cgi?id=1272845&action=edit After patch: ftdiff -s 8.25 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #54 from Bojan Smojver bojan@rexursive.com --- Created attachment 1272846 --> https://bugzilla.redhat.com/attachment.cgi?id=1272846&action=edit After patch: ftdiff -s 8.3 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #55 from Bojan Smojver bojan@rexursive.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #56 from Alexei Podtelezhnikov apodtele@gmail.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #57 from Satish Balay balay@fastmail.fm --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #58 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Werner Lemberg wl@gnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wl@gnu.org
--- Comment #59 from Werner Lemberg wl@gnu.org --- 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')...
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #60 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #61 from Werner Lemberg wl@gnu.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #62 from Adam Goode adam@spicenitz.org --- FreeType 2.8 should fix these issues.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Adam Goode adam@spicenitz.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends On| |1450581
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1450581 [Bug 1450581] freetype-2.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1437999 Bug 1437999 depends on bug 1450581, which changed state.
Bug 1450581 Summary: freetype-2.8 is available https://bugzilla.redhat.com/show_bug.cgi?id=1450581
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |RAWHIDE
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #63 from Bojan Smojver bojan@rexursive.com --- (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.?
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
Adam Goode adam@spicenitz.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed| |2017-05-21 13:28:53
--- Comment #64 from Adam Goode adam@spicenitz.org --- Not sure, you should try out F27 and see.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #65 from Satish Balay balay@fastmail.fm --- (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]
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #66 from Marek Kašík mkasik@redhat.com --- 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-p...).
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #67 from Kevin Kofler kevin@tigcc.ticalc.org --- The QtWebEngine package, and maybe also the Fedora Chromium package, would likely still be built against the system FreeType.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #68 from Bojan Smojver bojan@rexursive.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1437999
--- Comment #69 from Adam Goode adam@spicenitz.org --- 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.
fonts-bugs@lists.fedoraproject.org