Bug 238482

Summary: x11-fonts/fontconfig: Firefox print pre-formatting is HORRIBLE ("bitmap font by default")
Product: Ports & Packages Reporter: Ronald F. Guilmette <rfg-freebsd>
Component: Individual Port(s)Assignee: freebsd-gnome (Nobody) <gnome>
Status: Open ---    
Severity: Affects Some People CC: gecko, gnome, grahamperrin, greg, koobs, lightside, rgrimes, swills
Priority: --- Keywords: needs-qa
Version: LatestFlags: koobs: maintainer-feedback? (gnome)
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225744
Description Flags
good output
Screenshot of CUPS admin page -- Ubuntu/Linux
Screenshot of CUPS Admin page (print preview) - Firefox-67.0/Freebsd-12.0
fonts info
The index.html file for test
Disabled LONG_PCF_NAMES option for print/freetype2 port
Enabled LONG_PCF_NAMES option for print/freetype2 port
Installed package/port versions list
Firefox saved web page (complete) of CUPS Administration page none

Description Ronald F. Guilmette 2019-06-11 04:29:19 UTC
I have firefox-67.0_3,1 installed and running on a fresh new 12.0-RELEASE system.

For reasons that are not the least bit clear, both print preview(s) and actual printed output for even very simple web pages (e.g the administration page for CUPS, localhost:631) look absolutely abysmal, and they look MUCH worse than the print previews and/or the printed output for the exact same pages look over on my Ubuntu/Linux 18.04 system when I am also using Firefox 67.0 on that operating system.

I don't know what it is, but SOMETHING is going horribly wrong with Firefox's pre-print formatting of even simple text web pages, and the result is hardly even worth printing because it is nearly illegible.  And this is apparently only failing on FreeBSD, but NOT also on Linux/Ubuntu.

I will provide screenshots and/or scans of the (badly) formatted/printed pages if necessary, but  believe that this problem should be easy to reproduce.

P.S.  If I could figure out how to mark this bug report as URGENT, then I would do so.  Every other FreeBSD-specific bug I know of I can work around, but this one I can't.  I need this to work. I have no alternative.  On 12.0-RELEASE, Opera is crashing if the user even goes near the print menu (which I have already filed a spearate bug report on), and there's something broken in chromium that prevents it from properly forgrounding when run under the fvwm window manager (which I use).  So I have no other real choice but to continue using Firefox.  It would be most helpful if Firefox could just simply print web pages in a way that's fit for human consumption.
Comment 1 Jan Beich freebsd_committer 2019-06-11 05:01:12 UTC
HORRIBLE is not an objective evidence. I need at least example page, expected and broken output. If you're talking about fonts then see bug 225744.

There's no urgency or guaranteed support in volunteer projects. Please, ask for refund whoever told you otherwise.
Comment 2 Jan Beich freebsd_committer 2019-06-11 06:39:08 UTC
Created attachment 204975 [details]
good output

I can't reproduce on any page and don't have Ubuntu around to compare. Printed preview in Firefox looked OK years ago and still does.

Does the attached screenshot looks HORRIBLE?
Comment 3 Ronald F. Guilmette 2019-06-11 17:53:03 UTC
Created attachment 204989 [details]
Screenshot of CUPS admin page -- Ubuntu/Linux

Screen shot of CUPS Administration page (print preview) from Firefox 67.0 on Ubuntu/Linix -- FOR COMPARISON.
Comment 4 Ronald F. Guilmette 2019-06-11 17:55:21 UTC
Created attachment 204990 [details]
Screenshot of CUPS Admin page (print preview) - Firefox-67.0/Freebsd-12.0

Screen shot of CUPS Administration page (print preview) from Firefox 67.0 on FreeBSD (12.0-RELEASE) -- FOR COMPARISON.
Comment 5 Ronald F. Guilmette 2019-06-11 18:00:53 UTC
As requested, I have now provided screen shots of CUPS Administration page (print preview) as rendered by Firefox 67.0 on both (a) Ubuntu 18.04 / Linux and also, for comparison, the same screen shot of the same page from Firefox 67.0 running on FreeBSD 12.0-RELEASE.  I believe that the differences should be self-evident from these two screen shots, and that the latter should provide the requested objective evidence of the issue/problem.
Comment 6 Jan Beich freebsd_committer 2019-06-11 19:13:14 UTC
Bitmap fonts simply don't support anti-aliasing and generally only look good at very low resolutions. Firefox selects non-embedded fonts according to fonts-conf(5). Bug 225744 tried to make behavior match Ubuntu by default but apparently some users like how bitmap fonts look.

To see the list of bitmap fonts run "fc-list :scalable=false". To check if they'd be used by default run "fc-match serif", "fc-match sans-serif", "fc-match monospace". fontconfig behavior can be adjusted without creating fonts-conf(5) files simply by symlinking desired files from conf.avail/ to conf.d/ under /usr/local/etc/fonts/.
Comment 7 Ronald F. Guilmette 2019-06-11 20:18:08 UTC
Please allow me, respectfully, to offer the following observations/comments:

*)  I am a typical end-luser.  I know very little about anything, except in my own particular area of specialization, where I know a lot.

*)  I specifically know almost nothing about fonts.  I also DESIRE to know almost nothing about fonts.  I am not a web designer, and I have very important other work to attend to that precludes me from becoming on expert on fonts.

*)  It seems to me to be entirely self-evident that tailoring the set of fonts that are used, by default, by Firefox, in particular for print formatting, to the preferences of a minority of users who apparently prefer their hardcopy printouts to look like crap is inappropriate, and violates the fundamental design principal of Least Surprise.  (It is and will be highly surprising to the vast majority of ordinary FreeBSD end-lusers to see that their printouts look like crap when there is no compelling or obvious reason why they should.)

*) If necessary, I can and will get down and grovel around, performing any and all of the font-related extra tasks that you have graciously provided me with the instructions for, and which may/should make Firefox work properly.  I do not expect that I will have any undue trouble doing that.  However if the current status quo with respect to this very obvious issue is perpetuated into further and future FreeBSD releases, then I and everyone else who does not want their printouts to look like crap will be obliged to perform these same diddles each and every time a fresh FreeBSD install is performed.  I my opinion, this would represent the pointless creation of an ongoing REQUIREMENT for the majority of end users to repeatedly "fix" this bug, over and over again, for each new from-scratch FreeBSD install.  I believe that that would be an inappropriate choice/decision, and that the package/port maintainer should just simply fix this bug properly, for the majority of users, once and for all, and should instead instruct that small minority who actually like things to look like crap on how they may diddle THEIR systems to get those systems to provide that desired behavior.

P.S.  I really have neither knowledge of, nor any specific preferences or opinions about whatever specific fonts are being used by Firefox for print formatting over on Ubuntu specifically or Linux generally.  Thus, I do not care at all, and I do not have any reason to care at all if the fonts that Firefox on FreeBSD uses "match" or do not match those fonts specifically.  I would be perfectly happy if someone were to tell me that henceforth, Firefox on FreeBSD would be using the XYZZY font set, with the special gribble and mumblepooh options, as long as doing so would produce printouts that are competently legible.  (The current ones being used by default quite obviously fail in this regard, so pretty much anything else would likely be an improvement.)
Comment 8 Ronald F. Guilmette 2019-06-11 21:35:03 UTC
Created attachment 204997 [details]
fonts info

font list command output -- as requested
Comment 9 Ronald F. Guilmette 2019-06-11 21:48:25 UTC
Why was this PR closed?  It is in no sense "fixed" and the print output still looks utterly awful as I have demonstrated, and as Jan Beich explicitly confirmed by saying that bitmap fonts look bad except at low resolutions.

"Works as intended" ???

It is the maintainer's explicit and deliberate intention that print output from Firefox should, by default, look like garbage??

Furthermore, I have done as suggested and run commands to determine various things about the fonts on my system.  (See new attachement.)  There are no fewer than 895 different possible font files listed in the output from "fc-list :scalable=false".  How am I supposed to know which ones I need to make print output from Firefox look reasonable?

Apparently, Jan Beich knows how to get this working right, as he demonstrated when he posted the following attachment to this PR:


In that case the print preview looks excellent.

Now, if Jan Beich, or anyone else, can tell me how to make MY system produce such excellent print output from Firefox, then I will at least be able to work-around this self-evident bug for the time being.

As Jan Beich himself noted, it is not just me who has reported this self-evident bug, so this isn't just one lone person who has made mention of this issue:

Comment 10 Ronald F. Guilmette 2019-06-11 23:00:47 UTC
Thank god for Google.

I was just now able to find the proper solution/workaround for this problem here:


The command line:

cd /usr/local/etc/fonts/conf.d && ln -s ../conf.avail/70-no-bitmaps.conf

appears to resolve the problem/issue, at least for me, at least on this one system.

Given that I know, and knew, nothing whatever about either fonts or these various/numerous FreeBSD font configuration files, I am quite sure that I would not have been able to even guess the above command line in a thousand years if someone else had not already written it down for me.  (And I suspect that is probably true also of the majority of FreeBSD users.)

Fortunately, this was/is a problem that SEVERAL other people have already complained about, in the past, on the FreeBSD X.org forum (see thread above), and thus, I was able to find the proper fix/workaround.

It remains unfathomable to me however, as to why this problem hasn't been or can't just be fixed, once and for all, by the relevant maintainers.  (At this moment I don't know if this needs a Firefox-specific fix or if it needs fixing in the xorg package/port.  Either way, it is obvious that fixing the problem properly will not require anything much in the way of new engineering, so there seems to be little excuse not to fix the problem. Even Section 5.5.1 of the Handbook says right up front that the default xorg fonts are awful!)
Comment 11 Jan Beich freebsd_committer 2019-06-12 03:22:31 UTC
(In reply to Ronald F. Guilmette from comment #9)
> Why was this PR closed?

This isn't a bug that Firefox package maintainer can fix. Since you've re-opened let's try fontconfig maintainer.
Comment 12 Ronald F. Guilmette 2019-06-12 06:18:32 UTC
Thank you. That certainly sounds appropriate.

I do agree completely, based on what I know now, that this isn't likely to be in any sense a Firefox-specific issue, and I am happy to see it assigned to someone who may be closer to to both the actual problem and its remedy.

P.S.  Curiously, after disabling these troublesome bitmapped fonts on my system and killing and then restarting X, I noticed -zero- obvious ill effects from the change, and indeed, the only effect that I noticed at all was that now, the conversion of HTML to PDF, by Firefox, in preparation for printing a web page looks one hell of a lot better than it did before the change.

I hope that the fontconfig maintainer will take this into account.  There is no apparent downside to making this change.
Comment 13 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-15 04:08:51 UTC
(In reply to Ronald F. Guilmette from comment #9)

Hi Ronald,

I add the comment below both as a committer who seeks to improve the user experience as a high priority value, who looks at many many issues and interactions in Bugzilla, and as a member of the FreeBSD Bugmeister team to who manages issue tracking process in the project.

First, I'd like to respectfully request that you please dial down the rhetoric when using our issue tracker (or any other public project space) in future.

I/we understand (very well) that issues can be very frustrating (we report issues in other projects too), particularly if issues do not appear to be treated as importantly or in as timely a manner, as you may feel they are, or should.

Nevertheless, it is prudent in all circumstances to:

a) Assume good faith
b) Assume in advance there are things we as reporters don't understand or know in terms of the context or nuances of issues. Asking (unloaded/good) questions that seek to understand instead of letting our frustrations leak is much more productive.
c) Attempt to remain concise, objective and unemotional in the way we communicate. In particular, this means talking about the problem 'out there' from 'the same side' in a collaborative manner, and not contextualising issues in terms of me vs you,users vs maintainers or other potentially adversarial appearing ways.
d) For opensource projects, understand that resolving issues is based on the currency of collaboration and positive/constructive influence. Users that understand this tend to receive much more fruitful responses to their reports/concerns, and can save themselves a lot of unnecessary frustration.

We all seek to be understood, but in general, it pays to seek first to understand.

On the issue of this issue, I'd like to add a few points, and one proposal:

1) On the subject of "Works As Intended", and the "It is in no sense fixed" comment.

The only positive (forward moving) resolution type is "FIXED", which means, resolved by way of a specific action taken (in most cases, a commit).

All others are "non fix" resolutions, which varying differences. Resolution selection done right is usually is a process of exclusion, not positive selection, and in some cases, there can be overlap, or a not quite right fit.

Going through our resolution types, none fit more 'closely' than Works As Intended and it is/was the correct choice. This was made also made explicit with the added comment "Bitmap fonts simply don't support anti-aliasing and generally only look good at very low resolutions".

Said another way "it looks bad because rendering using bitmap fonts look bad"

At that point in the issue, there was no specific proposal for a change, which brings me to 

2) I propose to change this issue to sounds something like "Make default rendering font not be a bitmap one"

Finally, something that must be acknowledged is that font selection is a very subjective and widely scoped issue that has ramifications for software and use cases far beyond browser printing. It is in most cases that any default is not going to satisfy large groups, or many groups for different use cases, and the more important issue is that font selection ability for users is a) possible b) obvious to users c) easy to do
Comment 14 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-15 04:22:24 UTC
Analysis of actual underlying issues:

- Unclear to users that program font rendering relies on fontconfig
- Unclear to users what their options are for customising font rendering for their needs
- Bitmap fonts or not by default, affects different user classes for different cases (see bug 225744)
- To at least me: Unclear whether application specific font rendering defaults is possible currently, or possible at all

The primary question we should be asking (on behalf of our users), is:

In what ways can we improve their out of the box, and/or customisation, and/or initial learning experience for font rendering, considering that 'one size does not fit all' nature of font selection and program requirement diversity, with particular consideration given to ways to improve the port/package, if possible
Comment 15 Ronald F. Guilmette 2019-06-15 04:54:42 UTC
Thank you for your patience and your understanding that this is a user experience issue.  I and many others have made clear that the end user experience with the current default fonts configuration is entirely less than optimal.  (I have already posted links to other online comments by other parties who feel as I do about these bitmapped fonts, and about the pointless hassle they represent, and even the Handbook calls these fonts out as being ugly.)

I should note also that since I have changed my font configuration to rid myself of the abomination that is, apparently, bitmapped fonts, I have seen -zero- ill effects.  That fact in turn causes me to wonder why we are even still discussing this.  Is there some ambiguity or some specific person or group who is pushing for bitmapped fonts to remain as a default part of the default font configuration on FreeBSD?

If the bitmapped fonts aren't actually helping anybody, then it seems like rather a no-brainer to turn them off by default.
Comment 16 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-15 13:31:28 UTC
(In reply to Ronald F. Guilmette from comment #15)

1) That print pre-formatting with bitmap fonts is ugly is not being questioned

2) Others have seen ill-effects, just like you, but for the opposite case. This is why bug 225744 was mentioned several times. I would go through it thoroughly, seeking to understand the complete context of the 'opposite side of the argument' that you currently hold, which is to say, what is the nature and extent of issues when fontconfig defaults to using no-bitmap.conf. 

3) Doing no-bitmap.conf by default has already been attempted once, and it was reverted. Asking for the same thing again, would also mean taking on the burden to resolve 'at least' those issues raised the last time it was committed, if that were possible. Each side arguing why they're case is more important, or why the opposite case is less important is not a fruitful discussion.

4) We must find a solution, or solutions, if they exist, that are objectively better than the either/or case. This will be a function of collective self-motivated effort and research.
Comment 17 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-15 14:17:07 UTC
@Ronald Could you please provide the following information, *as attachments*, for anything more than 3 lines:

- Complete pkg version -v output

- If you use ports, the exact OPTIONS combinations that were used for firefox, fontconfig, freetype2, and anything other package you may think is relevant.

- Source code of the CUPS admin page (from the screenshots). In particular we're looking for the CSS/font settings of the page, so if they're not inline, please obtain everything associated with that page and bundle it up into a tarball.

- Snapshot of the current font-config conf.d configuration, the full contents of any 'non-standard' conf files, plus any other fontconfig configuration changes
Comment 18 Ronald F. Guilmette 2019-06-15 20:21:19 UTC
Just a few final words and then I don't think I'll have anything else of value to add regarding this problem/issue.

First, my own system is behaving very well, now that I've found and applied the magic incantation to make it work properly:

cd /usr/local/etc/fonts/conf.d && ln -s ../conf.avail/70-no-bitmaps.conf

My only point is that I have not opened and then reopened this PR just for myself alone.  *My* system is working great now, and it will continue to do so, I'm sure, until my next "upgrade".  Rather, I believed, and still believe, that a majority of FreeBSD users would be well served by not having to get down and grovel around in obscure font files, just in order to do something really simple and obvious like printing from a browser.  Others are, of course, entitled to hold different views and opinions on this point.

The only other thing I feel is worth noting is that, going by the public record, the original author of PR 255744 decided, in the end, to withdraw his proposed changes, apparently NOT because he HAD actually seen ill effects but only because, as he noted "it could be a big impact to many applications".  This is quite obviously only informed speculation, as opposed to hard evidence.  On the other hand, there is clear evidence that the enabling of bitmapped fonts, by default, causes multiple/numerous actual user problems.

Given the clear opposition to any change from the existing defaults, I would like to merely close by suggesting that, at a minimum, it would be appropriate, I think, to include the command line shown above, which fixes the problem, along with some minimal comments explaining why and when it might be useful, in the folliowing three places, so that no users for whom it may be of value would be likely to miss it:

*) Near the top of Section 5.5.1 of the Handbook.

*) Somewhere in Section 6.2.1 (Firefox) of the Handbook.

*) In the notices that are given at the end of the install process when doing "pkg install firefox" from the command line.

This would be a reasonable outcome, in my opinion.

I don't believe that I have anything further of value to say on this issue.  I will just note, in response to the immediately prior comment, that no, I have not been using ports.  I am only been using packages.  (I would supply the additional data requested, but doing so would seem to just be a waste of everyone's time at this point, so I'll pass on that.)
Comment 19 lightside 2019-06-15 21:42:08 UTC
Created attachment 205086 [details]
The index.html file for test

Hello. I was notified about this issue, when it was linked for bug #225744.

I investigated this issue a little, and I think, that it may be narrowed down to usage of following CSS style:
font-family: lucida grande, geneva, helvetica, arial, sans-serif;
if reading CUPS source files:

Possible to use following test case (index.html file) for a browser:
<!DOCTYPE html>
body {
  font-family: lucida grande, geneva, helvetica, arial, sans-serif;
<p>selected font-family:</p><p>The quick brown fox jumps over the lazy dog</p>
<font face="lucida grande"><p>lucida grande:</p><p>The quick brown fox jumps over the lazy dog</p></font>
<font face="geneva"><p>geneva:</p><p>The quick brown fox jumps over the lazy dog</p></font>
<font face="helvetica"><p>helvetica:</p><p>The quick brown fox jumps over the lazy dog</p></font>
<font face="arial"><p>arial:</p><p>The quick brown fox jumps over the lazy dog</p></font>
<font face="sans-serif"><p>sans-serif:</p><p>The quick brown fox jumps over the lazy dog</p></font>

Attached mentioned index.html file, just in case.
Comment 20 lightside 2019-06-15 21:53:38 UTC
Created attachment 205088 [details]
Disabled LONG_PCF_NAMES option for print/freetype2 port

(In reply to comment #19)
The possible issue for this case is missing (or not installed, if they are available) "lucida grande",  "geneva" fonts, but available "helvetica", which may point to either:
if using `fc-match helvetica` command.

% pkg which -o /usr/local/share/fonts/75dpi/helvR12-ISO8859-1.pcf.gz
/usr/local/share/fonts/75dpi/helvR12-ISO8859-1.pcf.gz was installed by package x11-fonts/font-adobe-75dpi
% pkg which -o /usr/local/share/fonts/100dpi/helvR12-ISO8859-1.pcf.gz
/usr/local/share/fonts/100dpi/helvR12-ISO8859-1.pcf.gz was installed by package x11-fonts/font-adobe-100dpi

Attached screenshot, when LONG_PCF_NAMES disabled for print/freetype2 port (and re-installation of x11-fonts/fontconfig to regenerate fonts cache):
% fc-match "lucida grande"
DejaVuSans.ttf: "DejaVu Sans" "Book"
% fc-match geneva
DejaVuSans.ttf: "DejaVu Sans" "Book"
% fc-match helvetica
helvR12-ISO8859-1.pcf.gz: "Helvetica" "Regular"
% fc-match arial
arial.ttf: "Arial" "Regular"
% fc-match sans-serif
DejaVuSans.ttf: "DejaVu Sans" "Book"

The DejaVuSans.ttf font is available from x11-fonts/dejavu port.
The arial.ttf is available from x11-fonts/webfonts.
Comment 21 lightside 2019-06-15 21:57:11 UTC
Created attachment 205089 [details]
Enabled LONG_PCF_NAMES option for print/freetype2 port

Attached screenshot, when LONG_PCF_NAMES enabled for print/freetype2 port (and re-installation of x11-fonts/fontconfig to regenerate fonts cache):
% fc-match "lucida grande"
DejaVuSans.ttf: "DejaVu Sans" "Book"
% fc-match geneva
DejaVuSans.ttf: "DejaVu Sans" "Book"
% fc-match helvetica
arial.ttf: "Arial" "Regular"
% fc-match arial
arial.ttf: "Arial" "Regular"
% fc-match sans-serif
DejaVuSans.ttf: "DejaVu Sans" "Book"

But if there will be "adobe helvetica" usage for some CSS style or html font face, the issue maybe the same:
% fc-match "adobe helvetica"
helvR12-ISO8859-1.pcf.gz: "Adobe Helvetica" "Regular"
Comment 22 lightside 2019-06-15 22:30:00 UTC
(In reply to comment #21)
For example, the `man fonts-conf` mentions about usage of alias for Helvetica:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">

There is some Metric-compatible fonts:

Also some page for reference about font configuration:

There is a possibility to create local ~/.fonts.conf (or as a symlink to ~/.config/fontconfig/fonts.conf file).
Possible to add the same contents as for "Reject bitmap fonts" (/usr/local/etc/fonts/conf.avail/70-no-bitmaps.conf) to it, if needed.

Some people tried to fix this (or similar issue) on the browser level:
Helvetica on Firefox: Overriding Fonts with CSS
Fix broken Helvetica fonts in Firefox
Comment 23 Greg V 2019-06-15 22:52:43 UTC
There's a much better solution than 70-no-bitmaps.conf. Much, much better.


Most people get it via the xorg-fonts metaport. So either its dependency on the bitmap fonts should be removed, or everything (well, xorg, metisse and tightvnc) should depend on xorg-fonts-truetype instead of xorg-fonts.

This is what (good) Linux distros have been doing.


Notice the "Required By" column.
Comment 24 Greg V 2019-06-15 22:57:29 UTC
btw, the only modern use case for bitmaps would be hipsters who use fonts from https://github.com/phallus/fonts

So yes, we shouldn't prohibit fontconfig from using bitmap fonts, we should just not install the awful xorg-fonts as a dependency of xorg itself.
Comment 25 Ronald F. Guilmette 2019-06-18 02:42:51 UTC
Created attachment 205192 [details]
Installed package/port versions list

Kubilay Kocak requested that I provide several bits of detailed information regarding my system so that this issue/problem could be further nailed down.  I am doing so now.  This is my "pkg version -v" output.
Comment 26 Ronald F. Guilmette 2019-06-18 06:25:38 UTC
Created attachment 205195 [details]
Firefox saved web page (complete) of CUPS Administration page

As requested, a copy of the saved (complete) CPUS administration page, as saved from Firefox (firefox.tar.gz).