Open
Bug 1243194
Opened 8 years ago
Updated 2 years ago
Firefox does not allow me to select a bitmap font as the default
Categories
(Core :: Graphics: Text, defect, P3)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox49 | --- | wontfix |
firefox50 | --- | wontfix |
firefox51 | --- | wontfix |
firefox52 | --- | fix-optional |
People
(Reporter: samuel.hodgkins, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [gfx-noted])
Attachments
(1 file)
186.23 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20160126104524 Steps to reproduce: I upgraded to Firefox 44 on Arch from Firefox 43 while having a bitmap font (Ohsnap/Ohsnapu) selected as the default font. Actual results: Apart from the other changes (these are likely resulting from a move to GTK3 which I was told happened and even though they aren't exactly desirable, it's not likely a bug.) upon starting Firefox 44 my UI font was no longer my previously selected font, but instead was a normal font (likely the default or whatever). This change is especially evident in the two images linked to below, which contain before & after pictures of Firefox 43 and Firefox 44. Before: Lower window in https://www.enlightenment.org/ss/display.php?image=e-569aad3d96e418.21368292.png After: Upper window in https://www.enlightenment.org/ss/display.php?image=e-56a7c8af39b0d7.30099795.png. Expected results: My font should not have changed in Firefox 44. (Ideally the theme wouldn't have changed at all but that is likely a GTK3 theme issue rather than Firefox.)
Dupe of recent bug 1243157 I guess.
Component: Untriaged → Graphics: Text
Product: Firefox → Core
Reporter | ||
Comment 2•8 years ago
|
||
That seems to be the opposite bug - there, text tha
Reporter | ||
Comment 3•8 years ago
|
||
For some reason the above comment was submitted while I was in the middle of typing it. Anyway, it seems to me like the linked bug is the opposite of this one - in it text that would normally be rendered as (sans-)serif is being rendered in a monospace font. In this one, text that I desire to be rendered in a specific Monospace font isn't and the desired font doesn't even appear in Firefox's list of available fonts in the settings page so I can't select it to be used even.
Comment 4•8 years ago
|
||
This is triggered by bug 1180560. The new font backend on Linux does not support bitmap fonts. See bug 1056479 comment 13.
Updated•8 years ago
|
Whiteboard: [gfx-noted]
Reporter | ||
Comment 6•8 years ago
|
||
The last comment on the bug marked as a duplicate mentioned support on another platforms / other browsers, and there appears to be some support in at least one unspecified browser on Windows as of October 2015. See https://medium.com/designing-medium/system-shock-6b1dc6d6596f#.q1l11tqdx
Comment 8•8 years ago
|
||
Hey there, OP. I had the same problem; not being able to display bitmap fonts in FF44. I looked into another bug mentioned in this thread, 1244212, and it was mentioned that setting gfx.font_rendering.fontconfig.fontlist.enabled to false in about:config would solve the issue. https://bugzil.la/1244212 I can confirm that it works; my bitmappies are back! :D (As an aside, I can't figure out how to embed URLs in here; markdown [text](URL) doesn't work...)
Comment 9•8 years ago
|
||
(In reply to b.adam.martin from comment #8) > Hey there, OP. I had the same problem; not being able to display bitmap > fonts in FF44. I looked into another bug mentioned in this thread, 1244212, > and it was mentioned that setting > gfx.font_rendering.fontconfig.fontlist.enabled to false in about:config > would solve the issue. > > https://bugzil.la/1244212 > > I can confirm that it works; my bitmappies are back! :D On the other hand, this will disable support for the unicode-range descriptor in @font-face rules, which may lead to bad results on some pages/sites that rely on it. Also, be aware that this workaround (i.e. the older fontconfig backend) is likely to be removed from the codebase at some point (in the fairly near future). We won't want to maintain two separate versions of the code indefinitely...
Comment 10•8 years ago
|
||
> this will disable support for the unicode-range descriptor in @font-face rules, which may lead to bad results on some pages/sites that rely on it. people who use custom fonts, especially bitmapped ones, probably are not concerned about it very much. > be aware that this workaround (i.e. the older fontconfig backend) is likely to be removed from the codebase at some point This is really valid point. I cannot clearly understand now why the bitmap fonts were excluded, maybe it is possible to reconsider that? Another option would be to make use of pre-rendered bitmap glyphs embedded into TTF fonts. I know it is possible to use them, for example, in WPF. It seems like freetype is able to use them, as well. But it would still be a pity that FF does not support the fontconfig way of setting up application's appearance.
Comment 11•8 years ago
|
||
Comment 13•8 years ago
|
||
Actually midori gtk+3 version on Arch, can select Terminus and other bitmap fonts without problem. The midori version at the bottom of the comment. I really don't understand why FF just dropped bitmap fonts support. Actually the comment 13 on bug 1056479 already mentioned: https://bugzilla.mozilla.org/show_bug.cgi?id=1056479#c13 Sounds incorrect to me, particularly the statement "We need to deprecate infrequently used features that make code more complex". I'm wondering if that's the way things will remain. This bug was filed on Jan 26th, and still shows up as new and unassigned. If there's no intention to fix it, can that be reflected in the status? I read about the workaround, but also that it will be removed, given it uses the old fontconfig backend. So if bitmap fonts are really not coming back to FF, it'll be good to know, and the workaround shouldn't be recommended. Thanks. ===================== Midori 0.5.11 GTK+ 3.20.5 (3.20.6) Glib 2.48.1 (2.48.1) WebKitGTK+ 2.4.11 (2.4.11) libSoup 2.54.1 cairo 1.14.6 (1.14.6) libnotify No gcr 3.20.0 granite No Platform X11; Linux x86_64 Identification Mozilla/5.0 (X11; Linux) AppleWebKit/538.15 (KHTML, like Gecko) Chrome/18.0.1025.133 Safari/538.15 Midori/0.5 Video Formats H264 [x] Ogg Theora [x] WebM [x]
Comment 14•8 years ago
|
||
(In reply to Javier from comment #13) > Actually midori gtk+3 version on Arch, can select Terminus and other bitmap > fonts without problem. The midori version at the bottom of the comment. Actually midori (and every other webkit-gtk-based browser) is behaving worse than current firefox by blurringly scaling bitmap fonts instead of picking the nearest size. And nobody seems to care about this: https://bugs.webkit.org/show_bug.cgi?id=142220
Comment 15•8 years ago
|
||
This is not limited to users who want a bitmap font. I hate most webfonts and I override most of them with rules in my ~/.fonts.conf. For example: <alias binding="same"> <family>@font-face:Graphik Meetup</family> <prefer> <family>Liberation Sans</family> </prefer> </alias> This, too, was broken after upgrade to 44+. The same workaround with fontlist.enabled=false also gave me back my local scalable fonts. Please don't ruin the workaround before font customizations, including mine, work as they're expected to.
Comment 16•8 years ago
|
||
(In reply to itz from comment #15) > This is not limited to users who want a bitmap font. > > I hate most webfonts and I override most of them with rules in my > ~/.fonts.conf. For example: > > <alias binding="same"> > <family>@font-face:Graphik Meetup</family> > <prefer> > <family>Liberation Sans</family> > </prefer> > </alias> > > This, too, was broken after upgrade to 44+. The same workaround with > fontlist.enabled=false also gave me back my local scalable fonts. This is an example of bug 1221146.
Comment 17•8 years ago
|
||
Should this be considered wontfix based on comment 4?
Flags: needinfo?(jfkthame)
Comment 18•8 years ago
|
||
I'm not sure. I think it's regrettable that we're regressing behavior for some (unknown) number of users here, but personally, at least, I don't currently have time to work on a solution here. However, if someone were to offer a patch that restores support for these fonts (through the new backend) without overly complicating it, I think we should seriously consider accepting it. Hence, I'm reluctant to just WONTFIX this and walk away.
Flags: needinfo?(jfkthame)
Updated•8 years ago
|
status-firefox49:
--- → wontfix
status-firefox50:
--- → wontfix
status-firefox51:
--- → wontfix
status-firefox52:
--- → fix-optional
Priority: -- → P3
Comment 19•7 years ago
|
||
http://gateway.glop.me/ipfs/QmZjZevrXm1znL3yYqM7yec7a4aQ2TwGx5KCwwDNhRHH7q/screenshot-firefox-52-fonts-suck.png okay it gets serious since 52.
Comment 20•7 years ago
|
||
I believe this should be fixed by bug 1350783. You can try out tomorrow's Nightly to verify.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•