Bug 18488 - Fontconfig 2.11.95 introduced regressions in font hinting
Summary: Fontconfig 2.11.95 introduced regressions in font hinting
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker major
Target Milestone: ---
Assignee: All Packagers
QA Contact: Rémi Verschelde
URL:
Whiteboard:
Keywords: IN_ERRATA6
Depends on:
Blocks: 17523
  Show dependency treegraph
 
Reported: 2016-05-19 13:55 CEST by Rémi Verschelde
Modified: 2017-03-06 16:03 CET (History)
6 users (show)

See Also:
Source RPM: fontconfig-2.11.95-1.mga6
CVE:
Status comment: A consensus needs to be reached about the default font hinting we want to use. Priority will be reduced if no progress is seen in the next two weeks.


Attachments
hintslight vs hintnone - bugzilla screenshot (260.35 KB, image/png)
2016-09-09 18:33 CEST, Rémi Verschelde
Details
hintslight vs hintnone - gmail screenshot (474.78 KB, image/png)
2016-09-09 18:33 CEST, Rémi Verschelde
Details
hintslight vs hintnone - hexchat screenshot (516.22 KB, image/png)
2016-09-09 18:34 CEST, Rémi Verschelde
Details
fonts before and after freetype update (101.19 KB, image/png)
2016-09-16 19:00 CEST, Nikita Krupenko
Details

Description Rémi Verschelde 2016-05-19 13:55:59 CEST
As reported on the devel mailing list [0], the update of fontconfig from 2.11.94 to 2.11.95 introduced regressions in the font handling in Cauldron.

Dimitri mentioned that:
> Seems like affected apps no longer pick up font hinting settings.

The fontconfig changelog [1] does mention "Add hintstyle templates and default hihtslight", so we should investigate to see if it's an upstream bug, or if we need to change things in our packaging.

The current situation makes fontconfig a blocker for the Mageia 6 release IMO, the visual regressions are very noticeable.

[0] https://ml.mageia.org/l/arc/dev/2016-05/msg00124.html
[1] https://www.freedesktop.org/wiki/Software/fontconfig/Devel/
Rémi Verschelde 2016-05-19 13:57:13 CEST

Blocks: (none) => 17523
Priority: Normal => release_blocker

Comment 1 Rémi Verschelde 2016-05-19 14:06:15 CEST
Comparing our spec [0] with that of Fedora [1], it seems we have quite a few differences and old patches, which are all labelled "(fc)" (I guess Fedora Core? Or was that the nick of a packager?), but no longer used by Fedora itself.

Some cleanup of our spec to drop unnecessary patches might help to fix this issue (assuming Fedora does not have the issue).

[0] http://svnweb.mageia.org/packages/cauldron/fontconfig/current/SPECS/fontconfig.spec?view=markup
[1] http://pkgs.fedoraproject.org/cgit/rpms/fontconfig.git/tree/fontconfig.spec

CC: (none) => thierry.vignaud

Rémi Verschelde 2016-05-19 14:06:25 CEST

CC: (none) => rverschelde

Comment 2 David Walser 2016-05-19 16:32:29 CEST
No upstream commits yet since 2.11.95 related to this:
https://cgit.freedesktop.org/fontconfig/

Someone can try a local build without the sources and patches, but they don't look like they would cause problems, and most look like they're correct.  Maybe the ones saying they are waiting for old Qt bugs to be fixed aren't needed.
Nikita Krupenko 2016-05-30 13:01:31 CEST

CC: (none) => krnekit

Comment 3 Thierry Vignaud 2016-06-30 18:59:45 CEST
What about the newly packaged 2.12.0?

Keywords: (none) => NEEDINFO

Marja Van Waes 2016-07-10 13:16:05 CEST

Blocks: (none) => 15527

Comment 4 Marja Van Waes 2016-07-12 16:32:53 CEST
(In reply to Thierry Vignaud from comment #3)
> What about the newly packaged 2.12.0?

Ping?

Does fontconfig-2.12.0-1.mga6 fix the problems?

CC: (none) => marja11

Comment 5 Rémi Verschelde 2016-07-12 16:43:08 CEST
Well in the meantime I installed Cauldron anew, and after 2 months I kind of forgot how it looked like previously.

I'm still not convinced the previous behaviour was restored, as I still have to zoom in websites like Gmail or GitHub to 110 - 120% to have a proper display in Firefox, which I did not need before the fontconfig update. But at the same time I'm not that much bothered anymore, so I don't know... guess it's a WORKSFORME now.

Resolution: (none) => WORKSFORME
Status: NEW => RESOLVED

Comment 6 Nikita Krupenko 2016-07-12 17:51:46 CEST
No, it doesn't work. The fonts are still broken.

Status: RESOLVED => REOPENED
Resolution: WORKSFORME => (none)

Comment 7 Chris Denice 2016-07-26 15:04:21 CEST
Yep, confirmed here as well!

CC: (none) => eatdirt

Comment 8 Chris Denice 2016-07-26 16:02:52 CEST
* I have tried to recompile without any patches, same result.
* Then, I played with the option mentioned there:

https://wiki.archlinux.org/index.php/Font_configuration

Creating /etc/fonts/local.conf with

cat /etc/fonts/local.conf

<match target="font">
  <edit mode="assign" name="hintstyle">
    <const>hintlight</const>
  </edit>
</match>

renders the fonts (almost?) as they were on mga5. So, it seems that within our new fontconfig package, hinting is indeed completely disabled.

In the Changelog, commit 98434b3392172233094cac25ade7225c93da9f1c, dated 02/12/15, they claim the new default is "hintslight". Checking the conf.avail file there: /usr/share/fontconfig/conf.avail/10-hinting-slight.conf

there is this line:

<edit name="hintstyle" mode="append"><const>hintslight</const></edit>


In my case, "hintslight" produce a rendering which is exactly the same at "hintnone". However,  "hintlight" (as I added in the local.conf file) does work. It sounds like a bug, I cannot imagine the fontconfig's folks having introduced two light modes "slight" and "light" :)
Comment 9 Chris Denice 2016-07-27 14:54:05 CEST
Investigating more...
The fact that "hintlight" renders as "hintnone" is expected, this is indeed not a matched case "hintfoo" would do the same.

* "hintslight" rendering is however the default, and gives a font rendering which is truly ugly.
* "hintmedium" does not look different in my case as "hintslight", the rendering is ugly.
* "hintfull", the rendering is nice, but it looks in all point similar to "hintnone".

Therefore, I am reverting my previous comment, I think hinting indeed works, the default behaviour is "hintslight", as mentioned in the Changelog, and this is why the fonts are actually ugly.

This suggests that, "hintfull" does not work, and "hintnone" produces an acceptable rendering.

Cheers.
Comment 10 Rémi Verschelde 2016-08-09 18:35:28 CEST
fontconfig 2.12.1 (changelog: https://www.freedesktop.org/software/fontconfig/release/ChangeLog-2.12.1) has an option build option to define the default hinting:

  --with-default-hinting=NAME
                          Enable your preferred hinting configuration
                          (none/slight/medium/full) [default=slight]

I requested a freeze push for 2.12.1 already, but did not use this option yet as I'd want to test the various configs first.

@Chris: Since you've worked on this a bit already, could you give it a try maybe? You could already start locally with the 2.12.1 version checked in SVN.
Comment 11 Chris Denice 2016-08-20 13:17:45 CEST
Sorry I was off till now, I'll have a look if not too late.
Comment 12 Chris Denice 2016-08-23 11:38:08 CEST
Ok, tested with default settings. It still looks ugly to me, as before. Others could confirm.

cheers.
Rémi Verschelde 2016-09-07 15:01:30 CEST

CC: (none) => pkg-bugs
Assignee: pkg-bugs => rverschelde

Comment 13 Rémi Verschelde 2016-09-09 18:23:04 CEST
I've tested `hintsnone`, and I'm actually not convinced that it looks better than `hintslight`, at least for the fonts I compared. I'll attach some comparison screenshots.
Comment 14 Rémi Verschelde 2016-09-09 18:33:26 CEST
Created attachment 8395 [details]
hintslight vs hintnone - bugzilla screenshot
Comment 15 Rémi Verschelde 2016-09-09 18:33:51 CEST
Created attachment 8396 [details]
hintslight vs hintnone - gmail screenshot
Rémi Verschelde 2016-09-09 18:34:04 CEST

Attachment 8395 description: hintslight vs hintsnone - bugzilla screenshot => hintslight vs hintnone - bugzilla screenshot

Comment 16 Rémi Verschelde 2016-09-09 18:34:28 CEST
Created attachment 8397 [details]
hintslight vs hintnone - hexchat screenshot
Comment 17 Rémi Verschelde 2016-09-09 18:40:57 CEST
BTW the commit that triggered the change in 2.11.95 is likely https://cgit.freedesktop.org/fontconfig/commit/?id=98434b3392172233094cac25ade7225c93da9f1c
Samuel Verschelde 2016-09-12 16:28:27 CEST

Status comment: (none) => Potential solution with new build flags in fontconfig, needs to be tested
QA Contact: (none) => rverschelde

Comment 18 Thierry Vignaud 2016-09-12 19:08:58 CEST
Also, bumping FreeType to 2.7 could help...
Comment 19 Chris Denice 2016-09-15 17:36:30 CEST
Ooops, I think we have lost antialiasing with the last version of freetype.

At least we now that the differences between hint* were far less dramatic than loosing antialiasing :D
Comment 20 Chris Denice 2016-09-15 17:39:29 CEST
@ Remi. Your attachment 8397 [details] is exactly what I see, that's enough to me to render the reading annoying, maybe it is because my screen is a 32', but the difference looks very clear to me.
Comment 21 Nikita Krupenko 2016-09-16 19:00:24 CEST
Created attachment 8418 [details]
fonts before and after freetype update

After updating freetype from 2.6.5-1.mga6.tainted to 2.7-1.1.mga6.tainted, the fonts are blurry too. In the attached screenshot: on the left fonts before the update (good), on the right - after (blurry).
Comment 22 Chris Denice 2016-09-21 11:32:45 CEST
I have just spotted another issue, which may deserve a bug report in itself, but I am posting it in here because it also affects the rendering and certainly interfere with hinting and all that:

xrdb -query | grep dpi
Xft.dpi:	96

while

xdpyinfo | grep dots
resolution:    101x101 dots per inch

according to https://wiki.archlinux.org/index.php/Font_configuration
this affects the font rendering and they mention this:

"Note: 96 DPI is not a standard. You should use your monitor's actual DPI to get proper font rendering, especially when using subpixel rendering."

On mga, we force the xft.dpi to be 96, it is hardcoded there:

tail /etc/X11/Xresources
! Fix the Xft dpi to 96; this prevents tiny fonts
! or HUGE fonts depending on the screen size.
Xft.dpi: 96

I changed to something closer to my screen resolution, and although different than before, the fonts look much nicer. I have no clue how we should fix this though.
Comment 23 Chris Denice 2016-09-21 13:42:03 CEST
Here we go, I have finally gotten the correct recipe.

@Nikita, you could check for your case too?

On my machine, the fonts are back to be as before, and beautiful according to my taste, with the following settings:

1) a matching dpi between xrdb -query | grep dpi and xdpyinfo | grep dots (101 in my case)

2) freetype 2 back to the old way. In my ~/.basrhc I had to add this line:

export FREETYPE_PROPERTIES="truetype:interpreter-version=35"

Any other value (38 et 40) renders small fonts unreadable and unfocused, I don't understand why they claim 40 is an improvement, it just looks like s... to me, whatever the hinting options are...

3) hinting to full:

cat /etc/fontconfig/local.conf

<match target="font">
  <edit mode="assign" name="hintstyle">
    <const>hintfull</const>
  </edit>
</match>
Comment 24 Rémi Verschelde 2016-09-23 09:46:52 CEST
De-assigning myself as I'm no longer sure what the right "fix" should be here. I've grown used to the new fontconfig defaults, and I guess someone more versed in font stuff would have to work on this.

Font hinting also seems to be a relatively subjective topic, so we'd need somewhat of a consensus to decide the way forward (a possibility being "it should be like it was in Mageia 5").

Status comment: Potential solution with new build flags in fontconfig, needs to be tested => A consensus needs to be reached about the default font hinting we want to use
Assignee: rverschelde => pkg-bugs

Comment 25 Chris Denice 2016-09-23 10:09:56 CEST
Hi Rémi, no pb, that's indeed 3 packages involved now and certainly a matter of taste. I guess this bug will be a wontfix, but we should maybe give a erratum and an easy way for people to recover the rendering they are used to.


FI, the folks at freetype are well aware of this problem and just don't care. Possibly myself and others see a lot of shitty fonts because we use old windowmanager with old subpixel rendering fonts, for which it is clearly stated that v40 deteriorates the rendering compared to v35. This thread is really a scandal [No that's no F... ok to destroy the quality of small fonts (personal opinion)]. 

http://lists.nongnu.org/archive/html/freetype-devel/2016-07/msg00091.html


"
The v40 code does not use any whitelist or other to handle certain fonts differently. It focuses on ignoring horizontal hinting and preventing the dirtiest hacks that dent more than they help. Modern fonts like Calibri, Cambria, Consolas, etc. render well with this approach, older fonts like Arial, Times New Roman, Georgia and Verdana display mostly fine with smaller details off. And that's okay. Basically, the harder a font tries to create pixel-perfect black and white bitmaps for old CRT monitors, the worse the results in the new mode. If someone finds ways to make older fonts render better without introducing lists or overly complex hacks, I'm interested.


PS: I recommend using the Liberation family of fonts (version 2 and up, important!) instead of Arial, Times New Roman and Courier. The family harmonizes much better internally and is equipped with much better ClearType-ready hinting. Fedora still ships some 1.x version, get the newer 2.0 with improved hinting and glyph coverage from here: https://fedorahosted.org/liberation-fonts/"
Comment 26 Nikita Krupenko 2016-09-23 17:15:12 CEST
(In reply to Chris Denice from comment #23)
> @Nikita, you could check for your case too?

Checked your solution after updating fontconfig and freetype.

> 1) a matching dpi between xrdb -query | grep dpi and xdpyinfo | grep dots
> (101 in my case)

xrdb -query says nothing in my case and xdpyinfo says that I have 96 dpi monitor.

> 2) freetype 2 back to the old way. In my ~/.basrhc I had to add this line:
> 
> export FREETYPE_PROPERTIES="truetype:interpreter-version=35"
> 
> Any other value (38 et 40) renders small fonts unreadable and unfocused, I
> don't understand why they claim 40 is an improvement, it just looks like
> s... to me, whatever the hinting options are...

Done.

> 3) hinting to full:
> 
> cat /etc/fontconfig/local.conf
> 
> <match target="font">
>   <edit mode="assign" name="hintstyle">
>     <const>hintfull</const>
>   </edit>
> </match>

Done, though I haven't even /etc/fontconfig folder. Also tried to put it into ~/.config/fontconfig.

I cannot say, that the solution helped. The fonts looks the same, bold fonts are still insanely bold, etc.  BTW, I use DejaVu fonts.
Comment 27 Chris Denice 2016-09-26 10:16:32 CEST
@nikita, my mistake:
the directory is /etc/fonts/. That's weird that the rendering does not change. You may also try with hintnone to check if this is better for DejaVu.
Comment 28 Nikita Krupenko 2016-10-01 23:36:20 CEST
(In reply to Chris Denice from comment #27)
> @nikita, my mistake:
> the directory is /etc/fonts/. That's weird that the rendering does not
> change. You may also try with hintnone to check if this is better for DejaVu.

Thanks! Now it works (I checked only 1-st version, with hintfull).

Though I still see blurry fonts in the applications like rpmdrake, but I think this is due to the root access required by the applications, and I haven't added export to the /root/.bashrc. Anyway, this is a minor problem.
Comment 29 Samuel Verschelde 2016-11-08 12:51:41 CET
I'm probably going to reduce the priority of this issue since it does not prevent using the distro and we even haven't a consensus about the default font hinting we want to use.

Anyone interested in having it solved before the release, consider it a gentle ultimatum :)
Samuel Verschelde 2016-11-08 12:52:24 CET

Status comment: A consensus needs to be reached about the default font hinting we want to use => A consensus needs to be reached about the default font hinting we want to use. Priority will be reduced if no progress is seen in the next two weeks.

Comment 30 Thierry Vignaud 2016-11-08 13:24:41 CET
Historically, that's exactly the kind of consensus that's impossible to achieve :-)
Comment 31 Chris Denice 2016-11-14 19:25:40 CET
Ultimatum accepted, and I am avoiding a war by switching this bug to WONTFIX.
We should mention in the erratum how to recover manually the "old" mga 5 fontstyle however.

If anyone wants a war, please reopen the bug... :) It is hardly fixable anyway, the folks@freetype are really moving into the opposite way, hiding their laziness for keeping the case by case support of old fonts under a CRT vs LCD bullshit argument... Would even be better to start a war upstream...

Status: REOPENED => RESOLVED
Resolution: (none) => WONTFIX

Samuel Verschelde 2016-11-15 14:49:13 CET

Keywords: NEEDINFO => FOR_ERRATA6

Samuel Verschelde 2017-01-17 10:29:39 CET

Blocks: 15527 => (none)

Marja Van Waes 2017-03-06 16:03:30 CET

Keywords: FOR_ERRATA6 => IN_ERRATA6


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