I noticed that on some websites, the letters "st" have a bow connection on the top. It's totally ugly and out of place. Environment: * Firefox nightly from 2013-11-19 * Linux, Ubuntu 12.04 Reproduction: 1. Create HTML page with charset ISO-8859-1 (Latin-1) 2. Text "Dienste" (just normal ASCII characters) 3. CSS font-variant-ligatures: discretionary-ligatures; Actual result: "st" has a bow on top between s and t. Screenshot attached. Expected result: Just the letters "st", no bow Observed on: http://www.openit.de/ Relevant CSS rules used by site: font-family: 'pt_sans_narrowregular'; -moz-font-feature-settings: "liga", "dlig"; font-size: 1.6em; font-variant-ligatures: common-ligatures discretionary-ligatures; font-weight: normal; text-rendering: optimizelegibility; Importance: I think ligatures are supposed to improve readability and/or make it prettier. Even though the site requested ligatures, this particular one is just wrong. It distorts the text instead of improving it.

The screenshot (attachment 8350032 [details]) doesn't look like it is using the pt_sans_narrowregular font; when I view http://www.openit.de/ here using Nightly, that text -does- use the webfont, and it doesn't have an "st" ligature. Could you confirm what font is actually being used for the "problem" text? Install the fontinfo add-on,[1] then select the "Internet-Dienste" text and choose Show Fonts in Selection from the right-click context menu. What I suspect is that the webfont is failing to load for you (why? check the Web Console for any font-related errors), so that the browser is using a fallback, and whatever fallback font it's finding on your system happens to include the "st" ligature. [1] https://addons.mozilla.org/en-US/firefox/addon/fontinfo/

Wouldn't the Devtools inspector Fonts panel give you that information too?

Ah, yes - that also works. I automatically think of the add-on because it's what I've been using for a long time, but the Dev Tools panel can also provide the info.

> the webfont is failing to load for you Yes, sure. I don't want web fonts. I disabled them many years ago. They are a security risk. > Devtools inspector Fonts panel Thanks for the tip. It's "Deja Vu Sans" here. It's the default font on many Linux systems. And I quite like that font. I don't want any other.

I don't know what the solution here would be, given that the font contains a bad ligature. Maybe a black- or whitelist for specific ligatures and/or fonts?

* { -moz-font-feature-settings: "dlig" off !important; } in userContent.css ?

(In reply to Ben Bucksch (:BenB) from comment #4) > > the webfont is failing to load for you > > Yes, sure. I don't want web fonts. I disabled them many years ago. They are > a security risk. Really? Well, it's your choice, but if you disable web fonts I'd expect that many sites will not display as the designer intended, and in some cases the resulting "failures" may be a bit problematic - e.g. text failing to fit within the intended area, or changed metrics significantly disrupting the expected layout. (In reply to Ben Bucksch (:BenB) from comment #5) > I don't know what the solution here would be, given that the font contains a > bad ligature. It's not "a bad ligature", it's a perfectly legitimate (though archaic) ligature. It's not enabled by default, so I don't think it's mere *existence* can be considered a fault in the font; it is only enabled if the (off-by-default) Discretionary Ligatures feature is used. > Maybe a black- or whitelist for specific ligatures and/or fonts? No. This example, at least, does not justify any kind of special-case code in Gecko to override what the font designer and CSS author have specified, which is what you're seeing: the font includes a *discretionary* "st" ligature, and the site's CSS turns on discretionary ligatures, hence you see it. Mats' suggestion should probably work to disable it (provided you don't run into a site that re-enables it with !important in its own rule). As for this report, I think it should be resolved:invalid. Everything here is working correctly as designed. One possible improvement I can see is that the site's CSS simply assumes its webfont will load, and doesn't consider fallback. Perhaps instead of using the -moz-font-feature-settings property in certain styles - where it will apply even if a fallback font is used - they could use it as a descriptor in the @font-face rule, so that it only applies if the specific webfont is in fact used. But that's a site authoring issue, not a Gecko bug.

I agree with Jonathan, fwiw. The suggested new feature seems to be way below the threshold for adding new features. And it seems it can be worked around in other ways.

> > They are a security risk. > Really? Oh, yes, considerably so. (In the security team, we had discussed this some time ago when there were serious exploits that we couldn't do very much about.) > It's not "a bad ligature", it's a perfectly legitimate (though archaic) ligature > I don't think it's mere *existence* can be considered a fault in the font I understand ligatures, as in "fi". I just object to this particular form. I've never seen this particular ligature *in this form* anywhere in any book. I do think that's a problem with the font, the symbol obviously must be coming from the font. However, that's the platform's default font, so it's not to be neglected. To fix, I'd 1) disable discretionary ligatures when the font prefs are set, because the chance of things going wrong is high, as you said 2) blacklist fonts, because it can happy to a user not touching prefs: the CSS rule can be used without setting a font, or the font might not be available. I also think this is fairly new, I started to see this recently on (a small number of different) sites, and don't remember seeing it before. I could be wrong, though. > it should be resolved:invalid. Everything here is working correctly as designed. I understand, but what matters to users is the result. And the result is wrong. The "st" here is not how "st" should look like. The form as you see it in the screenshot simply is not a proper latin letter. It's just wrong to make an arc above 2 letters. And given that this is the system default font for Linux, we better fix this. The CSS rule can be enabled independent from web fonts.

1) disable discretionary ligatures when the font prefs are set, because the chance of things going wrong is high, as you said. 2) blacklist fonts, because it can happen to a user not touching prefs: the CSS rule can be used without setting a font, or the font might not be available. And given that this is the system default font for Linux, we better fix this. The CSS rule can be enabled independent from web fonts, and the page author probably doesn't test all browsers on all platforms.

(In reply to Ben Bucksch (:BenB) from comment #9) > > > They are a security risk. > > > Really? > > Oh, yes, considerably so. (In the security team, we had discussed this some > time ago when there were serious exploits that we couldn't do very much > about.) We've done a lot of work in the past few years to address font-related security issues. (And if there are remaining issues, please file the appropriate bugs.) > > > It's not "a bad ligature", it's a perfectly legitimate (though archaic) ligature > > I don't think it's mere *existence* can be considered a fault in the font > > I understand ligatures, as in "fi". I just object to this particular form. > I've never seen this particular ligature *in this form* anywhere in any > book. It's not common, I agree; but that's why it is included in the font's Discretionary (off-by-default) Ligatures, rather than the Common (on-by-default) ones. http://www.amazon.com/gp/customer-media/permalink/mo6UWYLQ8092EV/1584562315/ref=cm_ciu_images_pl_link http://westcoastcatholicbooks.blogspot.co.uk/2012/06/welcome-to-unabridged-douay-rheims.html [has examples of various old ligatures, including the "ct" that's quite similar to this "st"] A fair number of other fonts include this and other similar ligatures, fwiw. http://www.adobe.com/type/browser/landing/hypatia/pdfs/Hypatia_Sans_natty_raja.pdf http://www.shadycharacters.co.uk/2011/06/the-ampersand-part-1-of-2/ > I do think that's a problem with the font, the symbol obviously must > be coming from the font. Yes, it's coming from the font. But it's not a "problem" with the font. It's clearly a deliberate design choice. The "problem", such as it is, is that this site is explicitly enabling the Discretionary Ligatures feature for text where it's not appropriate - the PT Sans font they're using as a webfont there doesn't even -have- a 'dlig' feature! - and is not ensuring that it applies only when a specific, known downloadable font is being used. > And given that this is the system default font for Linux, we better fix > this. The CSS rule can be enabled independent from web fonts. I doubt the CSS rule gets enabled widely -apart- from web font usage, as it's only when using a specific web font that the author can expect to know what features are available and how they'll appear. Given that web fonts are enabled by default, users are not going to see the "problem" on this site (and probably most other places) unless they have explicitly changed their settings.

> users are not going to see the "problem" unless they have explicitly changed their settings. (or the font download failed.) Re pref: When I set the "use my font" preference, I typically do not want to have stuff like this, I just want a normal font rendering without fancy custom styles. I think it's reasonable to disable ligatures when this pref is on. Or more generically: > I doubt the CSS rule gets enabled widely -apart- from web font usage, as it's only when > using a specific web font that the author can expect to know what features are available > and how they'll appear. The logical consequence of this is: Ligatures should be disabled whenever a system font (non-webfont) is used. Nobody can reasonably know what will happen with each character of all the system fonts on all platforms, and there are probably many suboptimal renderings that we can't fix, so that's a safe default.

(In reply to Ben Bucksch (:BenB) from comment #12) > The logical consequence of this is: Ligatures should be disabled whenever a > system font (non-webfont) is used. Nobody can reasonably know what will > happen with each character of all the system fonts on all platforms, and > there are probably many suboptimal renderings that we can't fix, so that's a > safe default. No, I don't agree. It'd be reasonable for an author who actually -does- want this ligature to appear - perhaps because they're aiming for a "pseudo-mediæval" look - to write something like @font-face { font-family: MyWebFont; src: url(.......); } font-family: "DejaVu Sans", "Hypatia Sans", MyWebFont, sans-serif; -moz-font-feature-setting: "dlig" on; with the expectation that if one of the listed fonts is installed, it'll be used (complete with discretionary ligatures), and if not, their provided webfont will be used as a fallback. IMO, you should direct your complaint here to the author of the site in question, as their use of the feature is unwise. But we will not go disabling features in Gecko just because they have the potential to be misused and result in poor-looking sites.

FWIW, Chrome shows the same "st" ligature there if the webfont is blocked and it ends up using DejaVu Sans instead.

> direct your complaint here to the author of the site It's not just this site. I prefer to fix my reader. Maybe I'm really picky about fonts, I need a Helvetica-style sans-serif font, everything else just hurts my eyes. (For me, that's one of the advantages of digitization: being able to adapt the reading device.) Thanks for considering this.

Did you try Mats' suggestion from comment 6? AFAICS, that ought to achieve what you want.

Thanks for the suggestion. This bug isn't about me personally or this particular site, but about improving things for all users. It is a certain school of thought. The background is explained at bug 86194. I was surprised that it specifically mentions font choices. It's not just me. I like the fact that Mats broadened the scope a bit, because there might be more offending CSS font rules, now or in the future. Again, thanks for your consideration.

Does Mats' suggestion sync across all of Sync enabled profiles? Having to remember to open up a css file and edit it every time I use a new machine is a hassle.