Am 28.07.19 um 20:35 schrieb David Rosenstrauch:

On 7/28/19 7:49 AM, Ralph Corderoy wrote:

...

Hi,

To save others' time, on upgrading to pango 1:1.44-1 today my terminal emulator and other programs displayed empty boxes instead of bitmap-font glyphs.  This is due to deliberate dropping of support by Pango. https://gitlab.gnome.org/GNOME/pango/issues/386

I don't think xterm(1) uses Pango given ldd(1)'s output, and it's happily displaying nice crisp glyphs.

Yeah, I just discovered this the hard way.  Very annoying.  Doesn't seem like there's any fix/workaround either.

DR

Hello, You can convert your BDF/PCF fonts to the "X11 bitmap only sfnt (otb)" OpenType format[1], which harfbuzz does support[2]. As far as I know, there are no tools that do this easily. (There are a few old projects on github that might give a starting point like bdf2ttf). You can probably script fontforge, though. I think it should also be possible to put all different bitmap sizes and codepages in a single file, but that might require more manual work. Adobe Type1 (PostScript) fonts can be converted to OTF with the Adobe Font Development Kit for OpenType (AFDKO)[3] (The AUR package is out of date). This format should be readble by harfbuzz as well. [1]: https://fontforge.github.io/bitmaponlysfnt.html#X11 [2]: https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/ "Note that Harfbuzz does support loading bitmap-only OpenType fonts." [3]: https://adobe-type-tools.github.io/afdko/AFDKO-Overview.html -- Andy

Hi David,

...

You can convert your BDF/PCF fonts to the "X11 bitmap only sfnt (otb)" OpenType format[1], which harfbuzz does support[2].

So these aren't "my" fonts. I'm using one of the bitmapped fonts that ships with X in xorg-fonts-misc as my terminal font.

`My' bitmap fonts are also packaged. $ fc-list :outline=False file | > sed 's/: $//' | > xargs -rd\\n pacman -Qqo | > sort -Vu bdf-unifont xorg-fonts-100dpi xorg-fonts-misc $

Does anyone know if there's any plans for these fonts to be usable with pango going forward?

There doesn't seem much point packaging a font in a format that isn't supported by most software. It would seem the upstreams, GNU and X.Org, should ship those fonts in the current and OpenType-bitmap formats, otherwise all packagers on every distro will come under pressure to convert during packaging. Speaking of conversion, ProgAndy mentioned an Adobe program. There's also https://github.com/fonttools/fonttools, packaged on Arch, that looks like it might be able to do it given its support for the EBDT and EBLC tables. And FontForge should be able to do it https://fontforge.github.io/generate.html lists ‘X11 bitmap only sfnt (otb)’ amongst the bitmap types. It's worth keeping an eye on https://gitlab.gnome.org/GNOME/pango/issues/386 If you look at the ‘History’ tab of https://bugs.archlinux.org/task/63297 you'll see I asked for this link to be added to the issue but that was refused. The mentioned blog post, deemed sufficent, leaves the reader stranded. gimp users are also impacted by this; their collection of bitmap fonts are now unusable. -- Cheers, Ralph.

On 7/29/19 8:31 AM, Ralph Corderoy wrote:

It's worth keeping an eye on https://gitlab.gnome.org/GNOME/pango/issues/386

Yep -- great issue to keep an eye on. "I was told that you intentionally removed support for this, is that true?" "Yes, that's why the blog post said so." "Well, but what are the upstream developers of pango-based applications supposed to do then?" "Nothing, there is no replacement. Pango doesn't support bitmap fonts anymore. Just like it said in the blog post." "Are bitmap fonts deprecated?" "..."

If you look at the ‘History’ tab of https://bugs.archlinux.org/task/63297 you'll see I asked for this link to be added to the issue but that was refused. The mentioned blog post, deemed sufficent, leaves the reader stranded.

Reading the linked issue will leave users just as stranded. So, I guess I'm a bit curious why you're so dead set on adding a link to the bug tracker. Do you know what a bug tracker is? It's a place for, well, tracking bugs. For triaging them, filtering based on their triage status, and discussing the efforts which have been expended towards fixing them. *There is no bug and nothing to fix. Pango does not support bitmap fonts anymore, and nothing other than convincing upstream to change their minds will make that stop being the case.* Since this is *not* the first time you've had this issue, Ralph, I would like to ask you: what is your divergent opinion on what a bugtracker is? - A personal mechanism to pass notes addressed to Eli Schwartz? (That last reopen request...) Please use email instead... Submitting a reopen request with the sole effort of arguing with the Bug Wranglers about why "you're wrong" for repeatedly refusing to reopen it, is *not* a productive way to discuss the matter. - A bulletin board for disseminating "vital" information to Arch users? If it's that important, we have a news feed. - A place for users to get together and discuss migration options? That's what a forum is for. - A place to collect all sorts of information on a subject, organize it into topics, index it for speedy access by users, and establish as the authoritative source for most of the Linux world to research, discover, and share information on the topic? It sounds like you've just described the famous Arch Wiki! Why are you so supremely dead set on necromantically raising a dead subject on the bugtracker, where it is difficult to find as well as being offtopic, when you could write a whole thesis paper on the subject, free of charge, on the wiki, and: - get thanked - have people ask you to write even more - provide a resource that, even next year or next decade, will be easily found and receive lots of visibility with no need to search - get a better page ranking in google while simultaneously raising the page ranking for the rest of the wiki Why do you insist on hiding information in the bugtracker where only Arch users today will find it, and Arch users tomorrow will *not* find it, nor will Debian or Fedora or Slackware or XXXX users ever find it at all (because they're not following recent Arch activity during the pango release cycle, and by the time some stable distro gets the pango update, everything has blown over). Please devote your wonderful desire to help out and share knowledge, in the recommended direction: improving the canonical documentation. :) It would be great if you could add a troubleshooting section to the Fonts article or something. If there was some sort of stable mechanism for indexing the information, and allowing users to update and refine their suggestions for living in a post-1.44 pango world, then I could even be convinced that it's worth adding a note to the bugtracker to that effect. -- Eli Schwartz Bug Wrangler and Trusted User

On 7/29/19 10:35 PM, David C. Rankin wrote:

So Gnome just KDE4'ed pango Type 1 support. It is bewildering why support simply can't remain. Nothing like pacman -Syu and having things break -- things that have been working -- forever.

Whatever the fight between Cairo and Pango over FC_face locking -- that seems like what needs to be fixed instead of simply dropping support for an entire class of fonts.

Progress. Oh well.

Yes, '"progress"' just about sums up gnome. Though I think KDE4 had a better excuse for being dropped. ;) Of course, given the blog post in which all this is being discussed, it would also be nice if pango actually had active contributors. Apparently, people really interested in making fonts better, are in rare supply. (Not that I can really sympathize, since I'm not even much interested in caring what fonts look like when they're installed on my computer.) -- Eli Schwartz Bug Wrangler and Trusted User