Open Bug 640134 Opened 14 years ago Updated 6 months ago

CSS option to disable anti-aliasing on fonts

Categories

(Core :: Graphics: Text, enhancement)

Product:
Core
Component:
Graphics: Text
Type:
enhancement

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: mimecuvalo, Unassigned)

References

Details

Attachments

(1 file)

usecase
38.60 KB, image/png
Details
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12) Gecko/20100101 Firefox/4.0b12 Build Identifier: Seems there was a spec for this a long time ago but dropped for whatever reason: http://www.w3.org/TR/WD-font/#font-smooth-prop webkit has the CSS property: -webkit-font-smoothing: [none | subpixel-antialiased | antialiased] Reproducible: Always
If we do this, we should only allow it in user/UA sheets, imo.
What are the use-cases for this?
Attached image usecase —
The usecase, at least for me, is that when working in things like the terminal or Vim, anti-aliasing on code drives me bonkers. See attached screenshot of a terminal for example. I'm developing a terminal for Firefox ( http://firessh.mozdev.org ) and as such would like to be able to disable anti-aliasing.
Is it possible for you to use a font with bitmap glyphs?
(In reply to comment #4) > Is it possible for you to use a font with bitmap glyphs? Hm, never thought of it - do you mean using a webfont? ( i.e. http://www.google.com/webfonts ) Don't those get automatically aliased as well?
(In reply to comment #5) > (In reply to comment #4) > > Is it possible for you to use a font with bitmap glyphs? > > Hm, never thought of it - do you mean using a webfont? ( i.e. > http://www.google.com/webfonts ) Don't those get automatically aliased as > well? Truetype fonts can contain bitmap glyphs for specific sizes. See http://partners.adobe.com/public/developer/opentype/index_ebdt.html I don't have any specific examples of such fonts but I'm sure there are some. These would not be antialiased if you render them at the correct size. These could be used in Gecko with @font-face.
(In reply to comment #6) > Truetype fonts can contain bitmap glyphs for specific sizes. See > http://partners.adobe.com/public/developer/opentype/index_ebdt.html > I don't have any specific examples of such fonts but I'm sure there are some. Gotcha. Well, although it's beyond me currently, I'll study up on it and try to convert a font to have it or find some fonts that possess this property. However, I do imagine on my end that users will eventually request the ability to change the font to something else and when they do I'd have to start packaging more processed fonts (that have bitmap glyphs) with the addon.
Maybe. I suspect that the results you get for non-antialiased drawing of arbitrary fonts are going to look pretty bad.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Is it possible for you to use a font with bitmap glyphs? > > > > Hm, never thought of it - do you mean using a webfont? ( i.e. > > http://www.google.com/webfonts ) Don't those get automatically aliased as > > well? > > Truetype fonts can contain bitmap glyphs for specific sizes. See > http://partners.adobe.com/public/developer/opentype/index_ebdt.html > I don't have any specific examples of such fonts but I'm sure there are some. > > These would not be antialiased if you render them at the correct size. > > These could be used in Gecko with @font-face. This would depend on platform behavior; DirectWrite, for example, seems to ignore embedded bitmaps except in CJK fonts, so it's not going to help for Windows users with h/w acceleration.
That's annoying. Could we just work around that if we wanted to?
Moreover, we cannot display remote bitmap fonts via @font-face at the moment because ots drops the bitmap tables. Workaround: turn gfx.downloadable_fonts.sanitize to off.
Sigh. It's a valid use-case, but I really wouldn't want to add a new CSS property for just this one use-case... Goodness me, maybe SVG Fonts are the answer :-).
(In reply to comment #8) > I suspect that the results you get for non-antialiased drawing of arbitrary > fonts are going to look pretty bad. Yes, in many cases they'll be awful at small sizes. It would be up to authors/users to apply such an option only to fonts that have been hinted appropriately for non-AA usage, if they want clean-looking results. (In reply to comment #10) > That's annoying. Could we just work around that if we wanted to? In principle, I suppose we could, but it'd mean digging through several font tables to find the bitmaps and blitting them ourselves - seems like a lot of effort for a fairly obscure edge case. I think a more reasonable approach would be to allow control over the rendering modes - subpixel (with or without fractional positioning), grayscale, or aliased - but I'm not sure how best to expose that control. Users already have some system-wide control via the ClearType Tuner control panel (on Windows) or other facilities depending on the OS, but the point here is that specific settings may be wanted just for a certain element. That suggests CSS control. However, I'm wary of allowing page authors to impose their font-rasterization preferences on users, overriding the user's settings, as this is often a very personal preference. That's what lies behind comment #1, I assume. But then, how many users would have any idea how to customize at that level?
(In reply to comment #12) > Sigh. It's a valid use-case, but I really wouldn't want to add a new CSS > property for just this one use-case... Goodness me, maybe SVG Fonts are the > answer :-). Not sure how serious that comment is :) .... does SVG provide control over antialiasing?
(In reply to comment #12) > Sigh. It's a valid use-case, but I really wouldn't want to add a new CSS > property for just this one use-case... No need for a new property, just a new value for an existing property: .term { font-family: monospace; text-rendering: aliased; } Maybe we should just do this. If authors misuse it to impose aliased rendering all over the place just because they happen to like it, and users _dislike_ the ragged results, it's up to users to frequent other sites. Just like if an author insists on using colors, fonts, etc. that look ugly to me - I'm unlikely to spend much time on those pages.
(In reply to comment #14) > Not sure how serious that comment is :) .... does SVG provide control over > antialiasing? With "full" SVG fonts you could put PNGs in your SVG, so as long as you display it at the right size, you get pixel-accurate results. I thought of a new text-rendering value and rejected it, but now that you suggest it again I think it would make sense ... some browsers still use text-rendering to control ligaturization and kerning, which is orthogonal, but I suppose that wouldn't really be a problem in practice.
Sorry to bring up an old bug, but I'd like to point out another use-case. This would be quite useful for a retro appearance on certain websites and apps, such as http://www.nitrome.com/ . This would also be useful for another site that I'm making, so it would be greatly appreciated if this could be implemented (although it would be even better if it could be standardised).
Another usecase for the font-smooth property are bitmap fonts which should never be anti-alised.
(In reply to Ben Scholzen from comment #18) > Another usecase for the font-smooth property are bitmap fonts which should > never be anti-alised. If they should never be anti-aliased, then it would be a bug for the implementation to do so, and there's no need for a property to control it.
(In reply to David Baron [:dbaron] from comment #19) > (In reply to Ben Scholzen from comment #18) > > Another usecase for the font-smooth property are bitmap fonts which should > > never be anti-alised. > > If they should never be anti-aliased, then it would be a bug for the > implementation to do so, and there's no need for a property to control it. Well, by bitmap fonts, I meant pixel fonts like those: http://www.fontsquirrel.com/fonts/list/style/Pixel
I need to take some screenshots at 200% zoom - is there a way to disable font anti-aliasing in Firefox for this purpose so they become clear and crisp?
I see this issue has been raised some time ago. Just to chime in on the conversation I think there should be a property to control whether or AA is applied to glyphs of a font or not, it should be down to the decision of the designer/developer based on his/her requirements for the project. Another use case to support this request would be the use of Icon fonts, such as the ones used by Github: https://github.com/blog/1135-the-making-of-octicons . This is widely becoming a common use case. As Ben Summers points out in this article: http://bens.me.uk/2012/web-font-icon-canvas-rendering by not providing a mechanism to disable sub-pixel anti-aliasing, we lose the crisp sharp edges of the glyphs as the designer intended. +1 for a similar feature as found in webkit to control this behavior.
Maybe this would be better implemented as an @font-face descriptor? It seems want to define how a font family is meant to be rendered, as opposed to declaring a style that it should be rendered in.
Now that bug 857142 has landed - can we maybe add a 'none' value to it as well?
Component: Layout: Text → Graphics: Text
Depends on: 857142
`font-smoothing: none` is essential now as Matt said its neede for font icons. Just open this in FF and Chrome -- https://github.com/rails/rails That is sad =(
(In reply to hiddih from comment #25) > `font-smoothing: none` is essential now > as Matt said its neede for font icons. Just open this in FF and Chrome -- > https://github.com/rails/rails > That is sad =( This comment is too vague to be useful. What platform are you talking about? If you're referring to OS X, would -moz-osx-font-smoothing:grayscale help? (It certainly makes a difference to the rendering of the icons for me - but github isn't using it.)
Sorry. Yep I'm talking about OSX. `-moz-osx-font-smoothing:grayscale` doesn't always help: http://codepen.io/H1D/pen/hpBkG
(In reply to hiddih from comment #27) > http://codepen.io/H1D/pen/hpBkG Yes, the Firefox rendering of this is antialiased. But the Chrome rendering, while it's "crisp", suffers from a different problem: inconsistent line thicknesses at some sizes. IMO, that looks worse than the antialiased but much more even rendering we get in Firefox.
> Chrome rendering, while it's "crisp", suffers from a different problem: inconsistent line thicknesses at some sizes - true. But still there are situation when I'd sacrifice consistent line thickness over "crisp" image. For example when font-size is fixed in a way, so this thickness issue won't arise. Anyway having an option is better that not to have it, isn't it?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: