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)

44 Branch
defect

Tracking

()

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)

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
That seems to be the opposite bug - there, text tha
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.
This is triggered by bug 1180560. The new font backend on Linux does not support bitmap fonts. See bug 1056479 comment 13.
Blocks: 1180560
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Whiteboard: [gfx-noted]
See Also: → 1244654
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
It works in both webkitgtk and qtwebkit.
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...)
(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...
> 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.
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]
(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
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.
(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.
Blocks: 1287686
Should this be considered wontfix based on comment 4?
Flags: needinfo?(jfkthame)
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)
I believe this should be fixed by bug 1350783. You can try out tomorrow's Nightly to verify.
See Also: → 1573135
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: