Bug 1437999 - FreeType bug causes Chromium misrendering of PDF
Summary: FreeType bug causes Chromium misrendering of PDF
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: freetype
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1450581
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-31 15:13 UTC by Adam Goode
Modified: 2017-05-22 14:55 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-21 17:28:53 UTC


Attachments (Terms of Use)
before the update (16.80 KB, image/png)
2017-04-05 13:46 UTC, Elad Alfassa
no flags Details
after the update (15.88 KB, image/png)
2017-04-05 13:47 UTC, Elad Alfassa
no flags Details
Before the patch, Liberation Mono Regular 8 pt (39.33 KB, image/png)
2017-04-17 22:49 UTC, Bojan Smojver
no flags Details
After the patch, Liberation Mono Regular 8 pt (36.06 KB, image/png)
2017-04-17 22:49 UTC, Bojan Smojver
no flags Details
After the patch, Liberation Mono Regular 8.25 pt (40.83 KB, image/png)
2017-04-18 00:30 UTC, Bojan Smojver
no flags Details
Before patch: ftdiff -s 8 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf (73.98 KB, image/png)
2017-04-20 03:50 UTC, Bojan Smojver
no flags Details
After patch: ftdiff -s 8 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf (77.24 KB, image/png)
2017-04-20 03:51 UTC, Bojan Smojver
no flags Details
After patch: ftdiff -s 8.25 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf (73.97 KB, image/png)
2017-04-20 03:55 UTC, Bojan Smojver
no flags Details
After patch: ftdiff -s 8.3 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf (88.57 KB, image/png)
2017-04-20 03:57 UTC, Bojan Smojver
no flags Details

Description Adam Goode 2017-03-31 15:13:58 UTC
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.

Comment 1 Marek Kašík 2017-04-03 14:43:39 UTC
Hi,

I've just tested the patch but it doesn't fix the issue. I'll look at it in more detail.

Comment 2 Marek Kašík 2017-04-03 14:50:33 UTC
I'm sorry, I was testing wrong file. The patch fixes the issue. I'll prepare an update with it.

Comment 3 Fedora Update System 2017-04-03 16:21:10 UTC
freetype-2.7.1-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-43db8d2e92

Comment 4 Fedora Update System 2017-04-03 16:21:21 UTC
freetype-2.6.5-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a14aa819ff

Comment 5 Fedora Update System 2017-04-04 22:22:41 UTC
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

Comment 6 Fedora Update System 2017-04-04 23:51:48 UTC
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

Comment 7 Kevin Kofler 2017-04-05 00:27:16 UTC
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.

Comment 8 Bojan Smojver 2017-04-05 06:11:27 UTC
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?

Comment 9 Elad Alfassa 2017-04-05 13:46:17 UTC
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)

Comment 10 Elad Alfassa 2017-04-05 13:47:40 UTC
Created attachment 1268963 [details]
after the update

You can see fonts are squished in the -3 version compared to the -2 version.

Comment 11 Adam Goode 2017-04-05 14:02:12 UTC
Elad: can you comment on the upstream bug report?
https://savannah.nongnu.org/bugs/?50470

Comment 12 Marek Kašík 2017-04-05 14:27:32 UTC
(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?

Comment 13 Elad Alfassa 2017-04-05 14:45:50 UTC
This is the default monospace font that gnome-terminal uses, I don't know its name. As for hinting setting, I'm using 'slight'

Comment 14 Marek Kašík 2017-04-05 14:58:03 UTC
Thank you for the information, I am able to reproduce it now.

Comment 15 Satish Balay 2017-04-05 18:16:24 UTC
(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

Comment 16 Alexander Ploumistos 2017-04-05 18:22:47 UTC
Fonts and bars in conky are also affected by the update to freetype-2.6.5-4.fc25.

Comment 17 Adam Goode 2017-04-05 22:06:54 UTC
Probably need to revert this until upstream figures out what to do.

Comment 18 Kevin Kofler 2017-04-10 10:05:21 UTC
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?

Comment 19 Marek Kašík 2017-04-10 10:37:24 UTC
(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.

Comment 20 Adam Goode 2017-04-11 17:24:58 UTC
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?

Comment 21 Satish Balay 2017-04-11 18:49:55 UTC
(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..

Comment 22 Bojan Smojver 2017-04-11 20:05:39 UTC
(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.

Comment 23 Adam Goode 2017-04-11 22:14:58 UTC
(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.

Comment 24 Bojan Smojver 2017-04-11 23:22:29 UTC
(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.

Comment 25 Alexei Podtelezhnikov 2017-04-13 02:40:49 UTC
(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.

Comment 26 Bojan Smojver 2017-04-13 02:54:25 UTC
(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).

Comment 27 Alexei Podtelezhnikov 2017-04-17 17:51:47 UTC
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?

Comment 28 Bojan Smojver 2017-04-17 22:48:14 UTC
(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.

Comment 29 Bojan Smojver 2017-04-17 22:49:11 UTC
Created attachment 1272177 [details]
Before the patch, Liberation Mono Regular 8 pt

Comment 30 Bojan Smojver 2017-04-17 22:49:35 UTC
Created attachment 1272178 [details]
After the patch, Liberation Mono Regular 8 pt

Comment 31 Alexei Podtelezhnikov 2017-04-17 23:13:49 UTC
(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.

Comment 32 Bojan Smojver 2017-04-17 23:59:16 UTC
(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.

Comment 33 Satish Balay 2017-04-18 00:21:41 UTC
(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)

Comment 34 Bojan Smojver 2017-04-18 00:30:04 UTC
Created attachment 1272202 [details]
After the patch, Liberation Mono Regular 8.25 pt

Comment 35 Satish Balay 2017-04-18 01:36:49 UTC
(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.

Comment 36 Alexei Podtelezhnikov 2017-04-18 03:10:13 UTC
(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.

Comment 37 Alexei Podtelezhnikov 2017-04-18 03:23:20 UTC
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.

Comment 38 Bojan Smojver 2017-04-18 03:33:45 UTC
(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.

Comment 39 Adam Goode 2017-04-18 03:45:22 UTC
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

Comment 40 Adam Goode 2017-04-18 22:15:57 UTC
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.

Comment 41 Bojan Smojver 2017-04-18 22:46:04 UTC
(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. :-)

Comment 42 Behdad Esfahbod 2017-04-18 23:03:45 UTC
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.

Comment 43 Behdad Esfahbod 2017-04-18 23:04:11 UTC
If someone files a bug against vte in gnome bugzilla, I can fix this.

Comment 44 Bojan Smojver 2017-04-18 23:27:52 UTC
(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

Comment 45 Adam Goode 2017-04-19 00:02:58 UTC
(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!

Comment 46 Bojan Smojver 2017-04-19 00:06:29 UTC
(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.

Comment 47 Behdad Esfahbod 2017-04-19 01:26:22 UTC
Unfortunately I was wrong.  Following up here: https://bugzilla.gnome.org/show_bug.cgi?id=781479

Comment 48 Alexei Podtelezhnikov 2017-04-19 13:57:10 UTC
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.

Comment 49 Adam Goode 2017-04-20 03:30:26 UTC
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.

Comment 50 Adam Goode 2017-04-20 03:47:15 UTC
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.

Comment 51 Bojan Smojver 2017-04-20 03:50:47 UTC
Created attachment 1272843 [details]
Before patch: ftdiff -s 8 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf

Comment 52 Bojan Smojver 2017-04-20 03:51:22 UTC
Created attachment 1272844 [details]
After patch: ftdiff -s 8 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf

Comment 53 Bojan Smojver 2017-04-20 03:55:32 UTC
Created attachment 1272845 [details]
After patch: ftdiff -s 8.25 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf

Comment 54 Bojan Smojver 2017-04-20 03:57:19 UTC
Created attachment 1272846 [details]
After patch: ftdiff -s 8.3 -r 96 /usr/share/fonts/liberation/LiberationMono-Regular.ttf

Comment 55 Bojan Smojver 2017-04-20 04:06:39 UTC
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.

Comment 56 Alexei Podtelezhnikov 2017-04-20 13:16:01 UTC
(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.

Comment 57 Satish Balay 2017-04-20 14:15:25 UTC
(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

Comment 58 Bojan Smojver 2017-04-20 20:00:51 UTC
(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.

Comment 59 Werner Lemberg 2017-04-20 20:40:03 UTC
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')...

Comment 60 Bojan Smojver 2017-04-20 21:52:36 UTC
(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.

Comment 61 Werner Lemberg 2017-04-28 06:39:47 UTC
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.

Comment 62 Adam Goode 2017-05-15 14:48:23 UTC
FreeType 2.8 should fix these issues.

Comment 63 Bojan Smojver 2017-05-21 08:41:08 UTC
(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.?

Comment 64 Adam Goode 2017-05-21 17:28:53 UTC
Not sure, you should try out F27 and see.

Comment 65 Satish Balay 2017-05-21 22:38:33 UTC
(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]

Comment 66 Marek Kašík 2017-05-22 09:48:44 UTC
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).

Comment 67 Kevin Kofler 2017-05-22 10:44:17 UTC
The QtWebEngine package, and maybe also the Fedora Chromium package, would likely still be built against the system FreeType.

Comment 68 Bojan Smojver 2017-05-22 11:32:02 UTC
(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.

Comment 69 Adam Goode 2017-05-22 14:55:47 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.