Closed Bug 1283802 Opened 8 years ago Closed 7 years ago

monospaced font selection no longer shows monospaced bitmap fonts

Categories

(Core :: Graphics: Text, defect)

45 Branch
x86
Linux
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 1350783

People

(Reporter: mirabilos, Unassigned)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

20.00 KB, application/octet-stream
Details
User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160601155443

Steps to reproduce:

After upgrading from 38 ESR to 45 ESR, I visited a text/plain page, such as:

• https://www.mirbsd.org/MirOS-Licence.asc (7-bit ASCII encoding)
• https://www.mirbsd.org/MirOS-Licence (UTF-8 encoding)

The page is displayed in a proportional sans-serif font instead of in a monospaced font. Monospaced text on regular websites also seems affected, so I did:

E̲dit → Preferen̲ces → Content → “Fonts & Colors” → 「A̲dvanced…」

The “M̲onospace” drop-down shows “monospace” as font name, which is, of course, not the name of a system font. I open the drop-down and try to select the FixedMisc font.

I’ve still got Firefox 38 ESR installed on the same system, so I start it in parallel and compare how the two operate, side-by-side.


Actual results:

I get a list of about a hundred fonts, almost all of them not monospaced, but FixedMisc is missing.

Firefox 38 ESR displays the aforementioned text/plain pages in FixedMisc; Firefox 45 ESR doesn’t.


Expected results:

FixedMisc, which is an X11 BDF/PCF system font properly registered both in the X11 font path and with Freetype (with the system-wide Freetype settings explicitly allowing bitmap fonts), shall be available to select, use, and be used to display monospaced text.

Firefox 45 ESR shall also display the aforementioned text/plain pages in FixedMisc.
Component: Untriaged → Graphics: Text
Product: Firefox → Core
This works for me in the current Firefox version. Is it still reproducible on your end?
Whiteboard: [gfx-noted]
(In reply to Thorsten Glaser from comment #0)
> FixedMisc, which is an X11 BDF/PCF system font properly registered both in
> the X11 font path and with Freetype (with the system-wide Freetype settings
> explicitly allowing bitmap fonts), shall be available to select, use, and be
> used to display monospaced text.

Since bug 1180560, which landed for mozilla-44 (so it'll be included in 45esr), bitmap fonts are not supported in Firefox. (See also bug 1056479 comment 13.)
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Since bug 1180560, which landed for mozilla-44 (so it'll be included in
> 45esr), bitmap fonts are not supported in Firefox. (See also bug 1056479
> comment 13.)

Should this be closed as INVALID?
(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #1)
> This works for me in the current Firefox version. Is it still reproducible
> on your end?

Yes, Nightly 51.0a1 (2016-08-08) still exhibits the problem.
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> (In reply to Thorsten Glaser from comment #0)
> > FixedMisc, which is an X11 BDF/PCF system font properly registered both in
> > the X11 font path and with Freetype (with the system-wide Freetype settings
> > explicitly allowing bitmap fonts), shall be available to select, use, and be
> > used to display monospaced text.
> 
> Since bug 1180560, which landed for mozilla-44 (so it'll be included in
> 45esr), bitmap fonts are not supported in Firefox. (See also bug 1056479
> comment 13.)

Äääääääääääääääääääääääääääääh, what now?

Can you *please* revert this? I *absolutely* *require* monospaced bitmap fonts.
(In reply to Thorsten Glaser from comment #5)
> (In reply to Jonathan Kew (:jfkthame) from comment #2)

> > Since bug 1180560, which landed for mozilla-44 (so it'll be included in
> > 45esr), bitmap fonts are not supported in Firefox. (See also bug 1056479
> > comment 13.)

> Can you *please* revert this? I *absolutely* *require* monospaced bitmap
> fonts.

And, for that matter, fontconfig and all those tools *do* support them.
Severity: normal → major
OS: Unspecified → Linux
Hardware: Unspecified → x86
Summary: monospaced font selection no longer shows monospaced fonts → monospaced font selection no longer shows monospaced bitmap fonts
(In reply to Thorsten Glaser from comment #5)
> (In reply to Jonathan Kew (:jfkthame) from comment #2)
> > (In reply to Thorsten Glaser from comment #0)
> > > FixedMisc, which is an X11 BDF/PCF system font properly registered both in
> > > the X11 font path and with Freetype (with the system-wide Freetype settings
> > > explicitly allowing bitmap fonts), shall be available to select, use, and be
> > > used to display monospaced text.
> > 
> > Since bug 1180560, which landed for mozilla-44 (so it'll be included in
> > 45esr), bitmap fonts are not supported in Firefox. (See also bug 1056479
> > comment 13.)
> 
> Äääääääääääääääääääääääääääääh, what now?
> 
> Can you *please* revert this? I *absolutely* *require* monospaced bitmap
> fonts.

Well..... for now, you can set gfx.font_rendering.fontconfig.fontlist.enabled to false in about:config (and restart Firefox) to revert to the older version of the font code. But this option is likely to disappear in a future update, as we won't want to maintain two copies of the font code indefinitely...

Can you explain *why* you "absolutely require" these bitmap fonts, to justify developers putting resources into this?

(And out of curiosity, do they work in applications such as LibreOffice or Chromium? It's my impression that an increasing amount of software is moving towards a scalable-fonts-only world...)
(In reply to Jonathan Kew (:jfkthame) from comment #7)
> (In reply to Thorsten Glaser from comment #5)
> > (In reply to Jonathan Kew (:jfkthame) from comment #2)

> > Can you *please* revert this? I *absolutely* *require* monospaced bitmap
> > fonts.
> 
> Well..... for now, you can set
> gfx.font_rendering.fontconfig.fontlist.enabled to false in about:config (and
> restart Firefox) to revert to the older version of the font code. But this

Thanks, this works, as a stopgap measure.

> option is likely to disappear in a future update, as we won't want to
> maintain two copies of the font code indefinitely...

I understand that. However, I’d like to request supporting bitmap fonts with
the new code as well.

> Can you explain *why* you "absolutely require" these bitmap fonts, to
> justify developers putting resources into this?

Yes: this particular bitmap font is the only one which contains all those
glyphs I need to render several documents, and only bitmap fonts can support
rendering tables, ERDs, etc. from plain UTF-8 as xterm does, i.e. with box
drawing characters, and so on. (The font spans 7583+42518=50101 glyphs,
halfwidth and fullwidth respectively; I admittedly don’t need all of them,
but many, *and* those glyphs are drawn to work well with each other, *and*
it makes documents look exactly the same as they do in the terminal, which
is relevant for quite some use cases.)

> (And out of curiosity, do they work in applications such as LibreOffice or
> Chromium? It's my impression that an increasing amount of software is moving
> towards a scalable-fonts-only world...)

I don’t really use LibreOffice, and I don’t touch Google spyware, so I have
no idea. The only application I regularily use (and at that only because my
employer requires it) that does not support bitmap fonts (besides the AOSP
operating system) is IntelliJ (because Java™, but well. On the other hand, I
regularily switch to xterm for working on code, and I only use IntelliJ for
the Java™ stuff I have to deal with at work, too, not for 95% of my development
work).

Scalable-only is a pure horror for those of us who grew up with the console
(DOS/BIOS/Hercules, in my case), since only bitmap fonts can truly work well
with all those nice use cases, plus those Unicode enabled us to do. Consider
https://www.mirbsd.org/~tg/pub/ERD.png which I once drew, over a decade ago
by now (this is a screenshot of “cat” inside xterm, of a plain text file).
This is only the beginning.

I’m outright willing to shell over, say, 10 € for the person who makes sure
that bitmap fonts stay supported, in case this is a bit of incentive needed ;-)
(In reply to Thorsten Glaser from comment #8)

> Yes: this particular bitmap font is the only one which contains all those
> glyphs I need to render several documents, and only bitmap fonts can support
> rendering tables, ERDs, etc. from plain UTF-8 as xterm does, i.e. with box
> drawing characters, and so on.

Surely there are TrueType/OpenType fonts that are fixed-width and support the box drawing characters, etc? Could you point to an example of such a document?

> Scalable-only is a pure horror for those of us who grew up with the console
> (DOS/BIOS/Hercules, in my case), 

I'm of that generation, too ;-) .... my early computer programming involved loading code from cassette tapes, writing programs by hand in 8080 and 6502 machine language, etc. But technology moves on....

There are definitely use cases that require fixed-pitch fonts. Whether it's essential for those fonts to be in a bitmap-font format is less clear to me.
Attached file usecases.tar
(In reply to Jonathan Kew (:jfkthame) from comment #9)
> (In reply to Thorsten Glaser from comment #8)
> 
> Surely there are TrueType/OpenType fonts that are fixed-width and support
> the box drawing characters, etc?

I haven’t found one, so far.

Furthermore, I’m regularily patching said bitmap font to make
glyphs look better in combination with others (it inherits from
both Fixed [Misc] and GNU Unifont, the latter being padded with
1x2 pixels), and to add new glyphs, so… it’s a matter of being
able to keep it up myself.

> Could you point to an example of such a document?

I’ll attach two examples I have at hand.

> > Scalable-only is a pure horror for those of us who grew up with the console
> > (DOS/BIOS/Hercules, in my case), 

> machine language, etc. But technology moves on....

I don’t buy this “argument”, sorry.

> There are definitely use cases that require fixed-pitch fonts. Whether it's
> essential for those fonts to be in a bitmap-font format is less clear to me.

Bitmap fonts have their pros as well: since they already define their
render size, the pixels rendered are perfect, for that one size. (And
usable for integral multiples of that size, even though not perfect.)
Also, bitmap fonts are not under copyright protection in the USA and
Germany, which may help in some use cases.

To be honest, I’m a bit offended that I have to defend wishing to use
a bitmap font here — can’t you just take this as user’s requirement?
(I’ve got no problem explaining some of my movement behind this require‐
ment to help you understanding it better, it’s just…)

Thanks!
(In reply to Thorsten Glaser from comment #10)
> Furthermore, I’m regularily patching said bitmap font to make
> glyphs look better in combination with others (it inherits from
> both Fixed [Misc] and GNU Unifont, the latter being padded with
> 1x2 pixels), and to add new glyphs, so… it’s a matter of being
> able to keep it up myself.
> 
> > Could you point to an example of such a document?
> 
> I’ll attach two examples I have at hand.

In both these examples, DejaVu Sans Mono comes fairly close to displaying them as intended; there are a few characters it doesn't support, leading to fallback and disruption of the spacing, but it should be feasible to extend the font to support everything needed -- and that would be a more future-proof approach than maintaining legacy-format bitmaps. (There are likely other large-repertoire monospaced fonts around, too; DejaVu just happens to be what I had on hand. Maybe worth trying Everson Mono?)


> To be honest, I’m a bit offended that I have to defend wishing to use
> a bitmap font here — can’t you just take this as user’s requirement?

I understand that, but implementing (and maintaining) support for it will require engineering resources, which are a scarce commodity. So its importance/urgency needs to be weighed against whatever else the engineers might be working on; and to evaluate that, it helps to understand why a user is asking for this particular feature, and what alternatives might or might not be available.
(In reply to Jonathan Kew (:jfkthame) from comment #11)

> fallback and disruption of the spacing, but it should be feasible to extend
> the font to support everything needed -- and that would be a more

Possibly, but changing a TrueType font is not as easy as changing a
bitmap font, and those all come with several variants of licences
that may or may not be feasible to use (though that is not currently
my concern). I’m more opposed to trying to hack something that comes
“close” to my current solution when I have a currently-working solution
which I know and can maintain (well, the font and console side), and
where I know I won’t have to occasionally hack stuff into.

Additionally, only bitmap fonts can have pixel-perfect rendering (at
one size only, but better than blurry rendering at all sizes), and
hinting is a whole different class of font design.

Finally, having things look the same between xterm and a web browser
helps a lot, visually, especially when switching between them often
(think ergonomy). And since xterm actually works b̲e̲t̲t̲e̲r̲ with bitmap
fonts (and is very ugly with most truetype fonts), I’m not going to
change that… on the contrary, I’ve brought my bitmap fonts to other
environments (Linux framebuffer console, PXELINUX, GNU GRUB) as well
to have a more consistent UI.

> > To be honest, I’m a bit offended that I have to defend wishing to use
> > a bitmap font here — can’t you just take this as user’s requirement?
>
> I understand that, but implementing (and maintaining) support for it will
> require engineering resources, which are a scarce commodity. So its
> importance/urgency needs to be weighed against whatever else the engineers
> might be working on; and to evaluate that, it helps to understand why a user
> is asking for this particular feature, and what alternatives might or might
> not be available.

OK, granted. But, as I already stated, I’m willing to put the occasional
monetary bounty on keeping it working. Not too much, as I do this as a
private individual from whatever low salary I get as a code monkey for
a dayjob, but definitely willing. Maybe this helps weighing…

… as for the rest, I hope I explained my motivations somewhat.
FWIW, I removed the gfx.font_rendering.fontconfig.fontlist.enabled code path in bug 1285533. I understand that this functionality was valuable to you, but it let us remove 3800 lines of otherwise unused and untested code. If the bitmap fonts functionality is valuable too you, I encourage you to investigate what would be need to add support back. However, I'd suggest that switching to a more future proof font might be a better use of your resources.
But thanks to lsalzman this should now be fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
(In reply to Jeff Muizelaar [:jrmuizel] from comment #14)
> But thanks to lsalzman this should now be fixed.

Ah cool! I’ll have to test a nightly build tomorrow then, I guess.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: