Open Bug 858002 Opened 12 years ago Updated 2 years ago

Font rendering broken for Helvetica Neue.

Categories

(Core :: Graphics: Text, defect)

Product:
Core
Component:
Graphics: Text
Version:
20 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: florian, Unassigned)

References

(
URL
)

Details

Open http://apolloner.eu/~apollo13/firefox_bug/ and see broken font rendering. The page includes a picture which shows it on my configuration (if it works fine on eg windows…), the same page displays nicely in Chromium. My system: Linux x86_64 Iceweasel 20 and also unbranded Firefox Nightly (as of today, 4.4.2013)
Does this affect -only- Helvetica Neue, or do you see issues with other webfonts as well? What is the version of fontconfig on your system?
I only see it with this font (or at least I didn't it notice this bad elsewhere); fontconfig version 2.9.0
OK, so not related to bug 857922, then. Does the font render poorly at all sizes? Does the problem persist in Safe Mode? (And an issue not directly related to the rendering problem, but is Helvetica Neue licensed for webfont distribution? I don't think Linotype's normal license terms cover that.)
(In reply to Jonathan Kew (:jfkthame) from comment #3) > Does the font render poorly at all sizes? Kind of, starting with 20px the font looks bold and the issue is gone. > Does the problem persist in Safe Mode? Yes. > (And an issue not directly related to the rendering problem, but is > Helvetica Neue licensed for webfont distribution? I don't think Linotype's > normal license terms cover that.) I have no idea, I just dumped it from the website which was using it and where I ran into the problem.
> > (And an issue not directly related to the rendering problem, but > > is Helvetica Neue licensed for webfont distribution? I don't think > > Linotype's normal license terms cover that.) > > I have no idea, I just dumped it from the website which was using it > and where I ran into the problem. Like any other content, you need to confirm that this is allowed. Helvetica Neue is a font whose rights are owned by Linotype, it's not an openly distributable font. http://www.linotype.com/1266/NeueHelvetica-family.html?site=webfonts
Well, I am not using this font and I am assuming the Website which uses it did purchase it (from the looks of it, since they have some fonts.com stuff on their site they probably purchased it there). Either way I just removed it from the example… Also fwiw I am not even sure if that's actually Helvetica Neue since I imagine you can write whatever you want into font-family (unless the woff/eot etc expose this information) -- I just called it that cause that's what the site uses in their font-family declaration. Licensing stuff aside, can we concentrate on the rendering issue? I'll happily test on the live site if there is anything to test.
FWIW, it -is- (or was) indeed Linotype's Helvetica Neue, as confirmed by the names, copyright, license, etc. within the font files. But as I said, that's not directly relevant to the rendering problem, I just mentioned it as I wasn't sure if you or whoever's involved might be unaware of the licensing issues with using proprietary fonts on the web. So for further testing, could you provide a URL of a site where you see the problem? It looks like the Linotype webfonts site generates its samples as graphics, not by using live webfonts, so that doesn't help for testing purposes.
Well that's where the problems start; I can give you a link but you won't be able to view it, without registering there -- that's the reason why I dumped the example to make it easier for you :( The site is http://newrelic.com -- sign up for a free account and access the monitoring panel, you should see it there (like this: http://imgur.com/sitlXz0 )
I'm not seeing your rendering problem here on my Linux machine (running ubuntu 12.04). It looks to me like it may be related to either graphics hardware/drivers or font rendering settings (e.g. antialiasing options) specific to your system. Could you post the contents of about:support, so we can see some more details of your configuration? That might give the graphics folk some clues...
Sure, here: http://apolloner.eu/~apollo13/firefox_bug/support.txt My fontconfig-config (sudo dpkg-reconfigure fontconfig-config): * Native * Automatic * No
I also have the following /etc/fonts/local.conf: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <edit mode="assign" name="rgba"><const>rgb</const></edit> <edit mode="assign" name="autohint"><bool>false</bool></edit> <edit mode="assign" name="hinting"><bool>true</bool></edit> <edit mode="assign" name="hintstyle"><const>hintmedium</const></edit> <edit mode="assign" name="antialias"><bool>true</bool></edit> <edit mode="assign" name="lcdfilter"><const>lcddefault</const></edit> </match> </fontconfig>
OK, so if you temporarily remove your local.conf (and reboot, maybe?), does that make any difference? Does it make any difference if you reset layers.acceleration.force-enabled (and restart the browser)? What version of freetype does your system have? >My fontconfig-config (sudo dpkg-reconfigure fontconfig-config): > * Native > * Automatic > * No That doesn't seem to correspond to anything on my ubuntu system. What do those settings refer to?
(In reply to Jonathan Kew (:jfkthame) from comment #12) > OK, so if you temporarily remove your local.conf (and reboot, maybe?), does > that make any difference? Nope, fonts look just odd cause the no longer have antialising applied then. > Does it make any difference if you reset layers.acceleration.force-enabled > (and restart the browser)? Nope, disabled that a few minutes after posting support.txt > What version of freetype does your system have? libfreetype6: Installed: 2.4.9-1.1 > >My fontconfig-config (sudo dpkg-reconfigure fontconfig-config): > > * Native > > * Automatic > > * No > > That doesn't seem to correspond to anything on my ubuntu system. What do > those settings refer to? In the above order: * Font tuning; Select 'Native' if you mostly use DejaVu (the default in Debian) or any of the Microsoft fonts. Select 'Autohinter' if you mostly use other TrueType fonts. Select 'None' if you want blurry text. * Enable subpixel rendering for screen (Automatic enables it for LCD panels) * Enable bitmapped fonts by default?
Here is an x-mag image of the broken example: http://imgur.com/pgcyhFq Looks as if at this size some parts are just not rendered at all?!
Indeed. How does it look with the other "Font tuning" options, Autohinter or None? (I realize they may make other stuff look worse, but just for experimental purposes...)
Ups, my previous statements where wrong, I have to rerun fontconfig after removing local.conf Switching to Autohint (and removing the autohint false from the xml) fixes it -- but that's ugly imo. Another way to fix this is to set the hintstyle to hintslight in the xml. I think you should be able to reproduce the issue by using my local.conf and running sudo dpkg-reconfigure fontconfig + restarting the browser. So to summarize: This is an issue of font-hinting, setting hinting to medium or full seems to trigger this bug (at least in conjunction with my aliasing settings etc…)
Are you able to reproduce the issue? What else would you need from me?
Any news on this?
I can reproduce the issue: 1. Open below link: https://www.linkedin.com/pulse/innovation-through-open-source-girish-maiya?trk=hp-feed-article-title-publish 2. You will see that the word "Probably" is not being rendered properly. If I edit the style and unselect the "font-weight:200" value it renders ok.
I forgot to say that this can be reproduced in chromium as well: Version 43.0.2357.130 Built on Debian stretch/sid, running on Debian stretch/sid (64-bit)
Same here, though I am on Version 39. Screenshot: http://i.imgur.com/EAKj0r2.png and Xmag: http://i.imgur.com/dq6FRPb.png
Flagging Jonathan. Jonathan, what are the next steps here?
Flags: needinfo?(jfkthame)
I think jdaggett should look into this. It's a regression from the Linux font-list changes. I assume it happens because the attributes used by our font matching code don't provide us with a distinction between the "normal" and "outline" faces (same family, weight, italic-ness, etc) and so which one we end up finding is pretty much arbitrary.
Assignee: nobody → jdaggett
Flags: needinfo?(jfkthame) → needinfo?(jdaggett)
(In reply to Jonathan Kew (:jfkthame) from comment #23) > I think jdaggett should look into this. It's a regression from the Linux > font-list changes. I assume it happens because the attributes used by our > font matching code don't provide us with a distinction between the "normal" > and "outline" faces (same family, weight, italic-ness, etc) and so which one > we end up finding is pretty much arbitrary. Argh, sorry -- ignore all that, I confused this with a different bug. :( Need coffee..... I'd still appreciate John having a look at this, but it may not be something we can do much about. I guess it's to do with how the font rasterizes under particular hinting or antialiasing settings, and it may be that the only answer is "don't use those settings with that font".
Assignee: jdaggett → nobody
(In reply to Jonathan Kew (:jfkthame) from comment #24) > "don't use those settings with that font" ...by which I mean user-level configuration settings, as controlled by ~/.fonts.conf or wherever your system keeps its fontconfig setup. There may also be GUI-level utilities for tweaking font-rendering settings; but the main point is that this may be dependent on settings outside of Firefox's control.
Works fine in Chrome though (and any other browser for that matter), I also have no ~/.fonts.conf anymore and no customization in /etc/ anymore. What I configured in Gnome tweak tool though is full hinting and rgba antialising.
Oh and to clarify the previous comment, no matter how I change the hinting there, it doesn't change the display in firefox (I can see a change in other programs though when I change something in gnome tweak tool)
I can reproduce the issue in chromium (Debian's implementation of chrome) as well, so I guess that is not a Mozilla Firefox bug: http://imgur.com/YtuW3cW If information about package versions, configs, etc... are relevant kindly ask and I will provide. PD: many thanks for your efforts
Interesting, this is what I get with Chromium Version 44.0.2403.89 Built on Debian stretch/sid, running on Debian stretch/sid (64-bit): http://i.imgur.com/VGPSphM.png
This isn't related to recent changes (it's an older bug obviously) and I'm not sure what the testcase and related steps are here. Seems like this is some sort of Helvetica Neue copy?
Flags: needinfo?(jdaggett)
Javier and Florian, can you please confirm you're both using the same Debian branch with all updates installed and the same Chrome version? If so then it's likely that this is a client-side configuration that causes the bug to show up. However it's still not clear to me if this is something we can fix in Firefox.
Any updates on this issue?
Anthony Hugues, sorry for my last reply. I can provide the details, but as stated in my previous comment (#28) I can reproduce the issue (incorrect render of word "Probably" in http://imgur.com/YtuW3cWhttp://imgur.com/YtuW3cW) in both, Mozilla Firefox (firefox-esr 45.3.0esr-1) and chromium (chromium 52.0.2743.116-2). So most likely not a Firefox issue I guess....
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.