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

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.

What about the newly packaged 2.12.0?

Keywords: (none) => NEEDINFO

(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

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.

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

No, it doesn't work. The fonts are still broken.

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

Yep, confirmed here as well!

CC: (none) => eatdirt

* 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" :)

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.

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.

Sorry I was off till now, I'll have a look if not too late.

Ok, tested with default settings. It still looks ugly to me, as before. Others could confirm.

cheers.

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.

Created attachment 8395 [details]
hintslight vs hintnone - bugzilla screenshot

Created attachment 8396 [details]
hintslight vs hintnone - gmail screenshot

Created attachment 8397 [details]
hintslight vs hintnone - hexchat screenshot

BTW the commit that triggered the change in 2.11.95 is likely https://cgit.freedesktop.org/fontconfig/commit/?id=98434b3392172233094cac25ade7225c93da9f1c

Also, bumping FreeType to 2.7 could help...

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

@ 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.

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).

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.

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>

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").

Assignee: rverschelde => pkg-bugs
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

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/"

(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.

@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.

(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.

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 :)

Historically, that's exactly the kind of consensus that's impossible to achieve :-)

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...

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