Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Here is my initial report against GNOME: https://bugzilla.gnome.org/show_bug.cgi?id=707777 However, it's not a GNOME bug. Changing the default font hinting to slight is one proposed solution. See the GNOME bug report for more information, discussion and some rendered samples showing the difference from freetype-2.4 to freetype-2.5. Thanks.
<match target="font"> <test name="family" compare="eq"> <string>Cantarell</string> </test> <edit name="hintstyle" mode="assign"> <const>hintslight</const> </edit> </match> would works if you are expecting to change the default hint style to slight for Cantarell only (according to the discussion the above URL)
That would be a good start at least. But is it possible to assign hintslight per rasterizer instead of per font name? All OpenType fonts are fuzzy with the current hinting in freetype 2.5 with Adobe's new rasterizer for OpenType merged. However, as Cantarell is such a large part of the experience of Fedora I would love to have that font fixed at least. Can this land in time for Fedora 20?
For f20, no. final change deadline has been gone and GA is coming soon. plus, that change may possibly affects a lot of fonts and it would be risky to do from now. You can try: <match target="font"> <test name="fontformat" compare="eq"> <string>CFF</string> </test> <edit name="hintstyle" mode="assign"> <const>hintslight</const> </edit> </match> instead. that may needs to be tested widely in f21 development timeframe and get a feedback on it because how it looks like is subjective. that said having this kinda recipe per fonts are our policy in Fedora and that would be safe to make any changes. so if you are aware of any other issues, that would be good to file a bug against that problematic font packages unless this kinda changes is needed for a lot of packages.
Can we get this into f21 now, then ? So it can get the wide testing it requires ?
OpenSUSE 13.1 (GNOME) renders sharp text even though they have freetype 2.5 so obviously they have solved any issues they had. > <match target="font"> > <test name="fontformat" compare="eq"> > <string>CFF</string> > </test> > <edit name="hintstyle" mode="assign"> > <const>hintslight</const> > </edit> > </match> This seems like a good solution -> getting all CFF fonts covered instead of having to enter rules for every single font. I don't know how to test this and I'm still on Fedora 19 but it seems legit?
(In reply to alexhultman from comment #6) > This seems like a good solution -> getting all CFF fonts covered instead of > having to enter rules for every single font. I don't know how to test this > and I'm still on Fedora 19 but it seems legit? Unfortunately no, you can't. matching on fontformat has been implemented in 2.11.0 (strictly speaking from the devel snapshot of 2.10.94) and not yet planning to push an update for f19 or older. so you need to try it on f20 at this moment.
No no, I'm not talking about trying this on Fedora 19 (the whole point of this bug report is that Fedora 19 already have perfectly sharp text). I was kind of wondering if you had written "pseudo code" or actually legit config that works. How do I test this? Where do I put that config, in what files and how?
Created attachment 836286 [details] full recipe to test just try to put the attached recipe under $HOME/.config/fontconfig/conf.d/
I tried that recipe and no go. fonts are still fuzzy. I'm not familiar enough with fontconfig to diagnose it though.
(In reply to Andy Wang from comment #10) > I tried that recipe and no go. fonts are still fuzzy. I'm not familiar > enough with fontconfig to diagnose it though. How did you test it? are you sure the font you saw is really Cantarell or any CFF fonts?
I can confirm the issue. Please note that "Monospace" is unaffected and looking crisp with hinting=full. However, I dropped your attachment into fontconfig/conf.d/ and also got no result. I also tried ~/.fonts.conf.d/ ... Is there anything I can help to sort that out?
I did with Cristoph did. Dropped the recipe into .config/fontconfig/conf.d Tried to do it globally in /etc/fonts/conf.d as well. According to gnome tweak tool, my Window Titles and Interface fonts are Cantarell Bold and just Cantarell.
Have you tried installing the 'freetype-freeworld' font rendering package from RPMFusion? I currently have it installed on all of my Fedora systems and I'm not experiencing the issues you describe when I use hint-slight.
(In reply to Akira TAGOH from comment #4) > <match target="font"> > <test name="fontformat" compare="eq"> > <string>CFF</string> > </test> > <edit name="hintstyle" mode="assign"> > <const>hintslight</const> > </edit> > </match> I could be wrong, but I think assigning hintstyle in fontconfig is overrided by gnome-settings-daemon/XSETTINGS. See https://bugs.freedesktop.org/show_bug.cgi?id=11838 I'm coming at this from the opposite direction (like fuzzy fonts, want hintmedium for CFF and hintslight for everything else). It seems like the crux of the issue is that with the new CFF rasterizer, CFF fonts are fuzzy at medium hinting and sharp at slight hinting, which is the opposite of all the other fonts.
Adding the conf.d snippet does fix Thunderbird, but doesn't fix window title bars or interface text in Gtk+ apps. That does suggest it's being overridden by XSETTINGS for Gtk+.
I've just upgraded two machines to F20 and now see this on both of them :( Most fonts are looking applicable with slight hinting. Changing the hinting with gnome-tweak-tool to medium or full reduces sharpness! Please, can anyone change the urgency to high as this is an embarrassing issue for a distro like Fedora?
just FYI, aside from XSETTINGS issue, abattiscantarell-fonts has a trick in 31-cantarell.conf to fallback to other fonts due to the glyph coverage in Cantarell font maybe with replacing the family name as the weak binding. for this reason, it may depends on the language how it works: $ LANG=en_US.UTF-8 fc-match Cantarell Cantarell-Regular.otf: "Cantarell" "Regular" $ LANG=ja_JP.UTF-8 fc-match Cantarell VL-PGothic-Regular.ttf: "VL Pゴシック" "regular"
I asked freetype what could be causing this and received this response. http://lists.nongnu.org/archive/html/freetype/2014-01/msg00011.html The workaround I'm using right now is downgrading freetype to 2.4.11 to use the old autohinter engine.
It looks like comment 19 of https://bugzilla.gnome.org/show_bug.cgi?id=707777 comes to the same conclusion.
just FYI, there are a comment from FreeType maintainer in the list: http://lists.freedesktop.org/archives/fontconfig/2014-January/005073.html
(In reply to Akira TAGOH from comment #21) > just FYI, there are a comment from FreeType maintainer in the list: > http://lists.freedesktop.org/archives/fontconfig/2014-January/005073.html That's interesting. I really like the dark, thick look of CFF fonts with medium hinting as they are now in F20, it's just the inconsistency with non-CFF fonts at the same hinting. If they're talking about changing the rendering internally, rather than swapping hint styles around for CFF, I'd like to be able to set it back somehow. Sorry if what I'm saying is already known or isn't an issue - just wanted to provide some representation in this bug for people who like dark fuzzy fonts. Also, from that link: "Given that the current version of the Cantarell fonts has broken hinting ..." I'm not sure about that, because Adobe's Source Sans Pro and Source Code Pro fonts (which are also .otf) look similar to Cantarell for me (fuzzy at hintmedium, thin at hintslight).
(In reply to Brian Marshall from comment #22) > (In reply to Akira TAGOH from comment #21) > > just FYI, there are a comment from FreeType maintainer in the list: > > http://lists.freedesktop.org/archives/fontconfig/2014-January/005073.html > > That's interesting. I really like the dark, thick look of CFF fonts with > medium hinting as they are now in F20, it's just the inconsistency with > non-CFF fonts at the same hinting. If they're talking about changing the > rendering internally, rather than swapping hint styles around for CFF, I'd > like to be able to set it back somehow. > > Sorry if what I'm saying is already known or isn't an issue - just wanted to > provide some representation in this bug for people who like dark fuzzy fonts. This bug report is not about whether you like fuzzy fonts or not - the point of this report is that the look of the render has changed, without there being any discussion about actually changing the look. It's an unwanted change, or regression if you want. Having fuzzier fonts should be discussed, not just happen out of nowhere. I for one, hate fuzzy fonts. And I think most people agree because we have had sharp text since the dawn of time.
(In reply to alexhultman from comment #23) > This bug report is not about whether you like fuzzy fonts or not - the point > of this report is that the look of the render has changed, without there > being any discussion about actually changing the look. It's an unwanted > change, or regression if you want. Having fuzzier fonts should be discussed, > not just happen out of nowhere. I for one, hate fuzzy fonts. And I think > most people agree because we have had sharp text since the dawn of time. That is hard to read from your initial statement. if that is the point, complaining that to fontconfig makes no sense because fontconfig isn't a rendering library and also complaining that here won't happens anything at all because freetype maintainer isn't in the loop of the discussion so that this looks like a Fedora specific issue. though Bugzilla isn't a better place to discuss the kind of that.
@Akira/Cosimo Are the issues with gamma and stem darkening being addressed in the font upstream and/or fontconfig? If not, should I create a bug(s) upstream? Per my comment 19 the font maintainer was informed but I do not see any action in upstream's git.
(In reply to Michael Cronenworth from comment #25) > @Akira/Cosimo > > Are the issues with gamma and stem darkening being addressed in the font > upstream and/or fontconfig? If not, should I create a bug(s) upstream? Per > my comment 19 the font maintainer was informed but I do not see any action > in upstream's git. I'm not sure for fonts. for fontconfig, I think there are nothing we can do at this moment unless this is a common problem for all of CFF fonts. I'm asking about it here and on other bugs too, but apparently no one is giving me any answers for that. so if this is Cantarell specific, it should be worked around in it rather than in fontconfig. this is why I reassigned this to the font.
I have created an upstream bug against the font to ping those who need to see this.
(In reply to Akira TAGOH from comment #26) > (In reply to Michael Cronenworth from comment #25) > > @Akira/Cosimo > > > > Are the issues with gamma and stem darkening being addressed in the font > > upstream and/or fontconfig? If not, should I create a bug(s) upstream? Per > > my comment 19 the font maintainer was informed but I do not see any action > > in upstream's git. > > I'm not sure for fonts. for fontconfig, I think there are nothing we can do > at this moment unless this is a common problem for all of CFF fonts. I'm > asking about it here and on other bugs too, but apparently no one is giving > me any answers for that. so if this is Cantarell specific, it should be > worked around in it rather than in fontconfig. this is why I reassigned this > to the font. I'm using Adobe's Source Sans Pro (package: adobe-source-sans-pro-fonts), another CFF font, and it has the same problem as Cantarell. I don't think it's Cantarell-specific.
*** Bug 995643 has been marked as a duplicate of this bug. ***
The 0.0.17 release of Cantarell addresses some of the issues.
Still blurry unfortunately.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
We are now at v0.0.24 (in F24/rawhide) and many more fixes should have been applied. Is this still reproducible in F24/rawhide?
Nothing much has changed. Yes, some of the glyphs have better shapes, but the issues related to darkening on non-HiDPI screens is still present.
And things are worse in F24 as well. Previously you could force the autohinter on which got things back to a sensible rendering. But upgrading from F23 to F24 changes something that makes the autohinter screw things up for "i" and "j" in sub-pixel mode. Unfortunately you cannot override the rgba hinting for just one font as Gtk's settings trumps the fontconfig ones. :/
So the workaround now is to downgrade to abattis-cantarell-fonts-0.0.18-1.fc24.noarch.rpm, which is the latest version without the buggy i and j, and apply this fontconfig: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE fontconfig SYSTEM "../fonts.dtd"> <fontconfig> <match target="font"> <test name="family"> <string>Cantarell</string> </test> <edit name="autohint" mode="assign"> <bool>true</bool> </edit> </match> </fontconfig>
Problem remains on Fedora 25 with abattis-cantarell-fonts-0.0.25-1.fc25.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Any progress on this? The version number seems to be the same for Fedora 26 at least.
None that I know of. The package maintainer in Fedora is also orphaning this package as of today. Since F26 introduced an soname bump to freetype and I was forced to finally give up the F19 version that used the old rendering engine I have had to live with the new font rendering and I'm becoming acclimated to it. :-/
This bug talks about the bugs in the font though, so any soname changes should not be an issue. :) The current workaround of downgrading the font and reconfiguring fontconfig still works for me on Fedora 26.
Is this still reproducible in Fedora-28?
Impossible to test as bug 1545149 made it impossible to get Cantarell of any version to render sharp. The end result (Cantarell being fuzzy) is still present in Fedora 28. But the cause is now either both bugs, or just the other.
(In reply to Pierre Ossman from comment #45) > Impossible to test as bug 1545149 made it impossible to get Cantarell of any > version to render sharp. Thanks for the reply Pierre Ossman. > > The end result (Cantarell being fuzzy) is still present in Fedora 28. But > the cause is now either both bugs, or just the other. As this is still present in Fedora 28, changing the version to 28.
Any update on this bug?
Also 29/30?
Created attachment 1557666 [details] fuzzy text Reproducible in Fedora-30. Checked it with Fonts-tweak-tools,text is fuzzy, if its not the case please provide Steps to reproduce the given issue. Please find attached screenshot.
Created attachment 1557732 [details] same window on my system I don't know how you get it to look like that, but it doesn't look like that on my system (Fedora 30, stock font settings AFAIR) at all. This is how it looks.
Here's a funny thing: *since I ran that fonts-tweak-tool thing* my fonts have started looking like your screenshot. I think fonts-tweak-tool actually does something that messes up the rendering itself. Now I have to figure out what it did, and undo it :(
Hmm, so I saw the funky font rendering in Firefox...after quitting and restarting it's gone. Definitely never saw it before running that font tweak tool thing.
so I think when we ran fonts-tweak-tool, added Cantarell font and closed it, fonts-tweak-tool generated default template file ~/.config/fontconfig/conf.d/000-fontstweak-ezfc.conf and that changed the rendering.
(In reply to Adam Williamson from comment #51) > Here's a funny thing: *since I ran that fonts-tweak-tool thing* my fonts > have started looking like your screenshot. I think fonts-tweak-tool actually > does something that messes up the rendering itself. Now I have to figure out > what it did, and undo it :( If what you did is like https://bugzilla.redhat.com/attachment.cgi?id=1557732, then no surprised it does. Though thinking about better parameters for everything should be difficult and hard to optimize. that said, things like your screenshot makes no sense indeed. sub-pixel rendering and hinting should be enabled by default at least. Though this is a tweak tool and targetting a power user who knows what it does. but it should be improvements in fonts-tweak-tool.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days