Or you could just deploy your bitmap fonts in an OpenType wrapper? This really feels like people who have made their lives more difficult for dubious fashion, and instead of dealing with the actual engineering issues discussed (i.e FreeType being a pain to deal with, HarfBuzz not going out of their way to write a BDF loader), are blaming the project for having it out for them or wanting to break things instead of having to make the code worse for a minority of users who explicitly want to use something inferior.
Shades of the Mozilla XUL discussion, except instead of an interesting engineering analysis on why it happened, this is just a peanut gallery descending on an internal issue tracker.
I feel like GUI programming needs an analogous rule to the Linux Kernel’s “We do not break user space!” rule. If your decision to remove something causes distressed comments and workaround tutorials to spring up like mushrooms, you probably blundered - no matter the amount of cleanup it allows you to do in your code base. It is really frustrating when the maintainers of an ubiquitous library mark your bug report as “wontfix” and close it. On the other hand, will you, the user, step up, take on the burden of this problem and straighten it all out? My experience is that if you submit a clean bugfix and are willing to talk and work with people, they will accept your PR.
GUI programming for Windows in C and C++ pretty much follows the “We do not break user space!” rule. Cake, for example, is a Windows 1.0 application that I ported to Win64 as a weekend hack.
I think these are the only code changes that would be needed to get the application working on Win32.
This was a pretty bad one when it happened. I solved it by switching the affected tools to non-pango dependent alternatives.
discussion locked
I’m not too surprised they chose to double-down and mute the discussion. A lot of decisions like this is why the open desktop experience is a disaster.
This isn’t exclusive to GNOME, but the whole ecosystem suffers from it, e.g. PDF viewers: KDE’s Okular’s new smooth scroll “feature”, or mupdf’s “trim margins” feature request.
I’m surprised bitmap fonts survived for so long. They should have been removed from everything ages ago! The presence of this ancient technology is still causing unpleasant surprises sometimes.
Can you describe the OS, desktop environment, browser, text editor, IDE, etc. you’re using? I love bitmap fonts because of their enhanced clarity and design, but most software is unable to handle them properly. I have yet to find a setup that lets me use bitmap fonts across the board, from desktop environment all the way to the applications. SerenityOS seems to do really well on this front.
Try using Ripcord https://cancel.fm/ripcord/ for Discord. It supports any font you like, and additionaly it’s a fully native Qt application, not an Electron crap.
Fonts more than many other things in normal graphics depends on the ‘context of use’ and what price you must pay versus the price you can tolerate paying. It’s your cycles and all that but the vector step is a big and pricey complexity leap – rough incremental cost (anything non-printer):
bitmap ascii-set? font in cache and straight masked bitblt (< 100loc range)
(arguably hershey vector font set kind of things fit in here somewhere, but mainly embedded use?)
bitmap to intermediate-vector->bitmap? fetch+mul per pixel, heavy format parsing+intermediate buffer+glyph cache+device dependent shaping+raster cache and complex data formats (multiple support libs and years of work)
shaped/substitutions/ligatures? all string and layouting operations more complex, table preprocessor/lut
gpu drawing context? atlas packing cache management, reduced feasible set of active use glyphs
ZUI? mipmap levels and filtering..
3D/VR? offline (m)SDF gen, manual fixups for troublesome glyphs..
I use most of that range daily, whenever possible though, bitmap for the win (and cycles).
The thing with that discussion though is like, while bitmap fonts may have some space optimization weirdness that makes parsing a little bit of work, for what they are, it doesn’t register on the complexity scale. Heck, those fun emojis are embedded PNGs forcing both bitmap management and pixel-scaling to be there anyhow..
Given two particular names in that thread, I’d go with ‘obstinate’..
I couldn’t actually read this submission as Gitlab was too much for my current internet connection, but I didn’t like this at all. I wouldn’t have had a huge problem with it except for the fact that by default I find scalable fonts to be very unreadable on non-high-resolution screens.
This might just be personal opinion, and since getting a HD display it hasn’t been an issue for me, but I do wonder whether it was another case of the developers having better-than-average (or even better than the lowest reasonable) devices and dismissing anyone in a different situation.
IMHO this is about a small minority opting into choosing an outdated technology (bitmap fonts) with serious limitations but advantages on their specific use-case and then blaming the developers for breaking their workflow.
Bitmap fonts stopped being universally useful with the decline of dot-matrix printers in the late 80ies, about 40 years ago and their usefulness gradually declined over the years as we got higher resolution displays, Unicode and lately very high resolution displays meant to run at 2x.
People still preferring bitmap fonts do not want to print them, have 1x monitors and use nothing but English. And they want maintainers to continue to support 40 years old technology in addition to all the new requirements around font rendering for the fonts that everybody uses because it’s convenient for them.
No machine made in the last ~35 years is too weak to handle vector fonts. In this instance, the argument about developers running too powerful hardware really doesn’t count any more
the argument about developers running too powerful hardware really doesn’t count any more
No one said “too powerful”; the relevant question is whether developers buy fancy new hidpi displays and forget about the many users who are happy to stay on older displays with lower resolution where bitmap fonts look better.
that is in the eye of the beholder (ever since anti-aliasing has become possible I personally preferred vector fonts - and the vast majority of users seem to agree considering the prevalence of bitmap fonts these days) and even disregarding the HiDpi support, the vector fonts still have other advantages (like being printable. or having unicode support).
Besides, bitmap shapes are still supported - if they are inside of an OpenType container. So a conversion of the existing fonts should totally be possible for those cases where going to a technology invented 40 years ago and widely adopted has too many drawbacks for a specific user.
In my original comment I said I wouldn’t have minded except the new system looked ugly to me by default. As far as I can tell I didn’t say anything that my opinion was fact or the only right way.
You keep coming back to printability and unicode. Printing totally confuses me as when I used bitmap fonts I printed with them. I’d like to clarify with unicode - are you talking about composable glyphs? I’ve had success using bitmap fonts with CJK characters, but I can assume they wouldn’t work as well with something like t҉h߫i͛s͕.
I’d like to clarify with unicode - are you talking about composable glyphs
The amount of characters which would need to be created is way too big for bitmap fonts where each size would need its glyphs to be manually created and opimized. Thus the amount of available bitmap fonts with reasonable amount of unicode characters is relatively small (in-act, I only know of GNU Unifont which also only contains 5 sizes and still weighs in at 9MB)
Or you could just deploy your bitmap fonts in an OpenType wrapper? This really feels like people who have made their lives more difficult for dubious fashion, and instead of dealing with the actual engineering issues discussed (i.e FreeType being a pain to deal with, HarfBuzz not going out of their way to write a BDF loader), are blaming the project for having it out for them or wanting to break things instead of having to make the code worse for a minority of users who explicitly want to use something inferior.
Shades of the Mozilla XUL discussion, except instead of an interesting engineering analysis on why it happened, this is just a peanut gallery descending on an internal issue tracker.
I’ve written a tutorial on how to convert PCF/BDF fonts to be Pango/Harfbuzz compatible. I hope this helps some people.
The people complaining seem to be font end-users, not font packagers.
I feel like GUI programming needs an analogous rule to the Linux Kernel’s “We do not break user space!” rule. If your decision to remove something causes distressed comments and workaround tutorials to spring up like mushrooms, you probably blundered - no matter the amount of cleanup it allows you to do in your code base. It is really frustrating when the maintainers of an ubiquitous library mark your bug report as “wontfix” and close it. On the other hand, will you, the user, step up, take on the burden of this problem and straighten it all out? My experience is that if you submit a clean bugfix and are willing to talk and work with people, they will accept your PR.
GUI programming for Windows in C and C++ pretty much follows the “We do not break user space!” rule.
Cake, for example, is a Windows 1.0 application that I ported to Win64 as a weekend hack.
I think these are the only code changes that would be needed to get the application working on Win32.
I saw one of the participants’ name turn up and instinctively knew that it would turn into an unpleasant outcome that would leave everyone worse off.
My approach is to stay as far away from the Gnome project and that individual as possible, and it kinda works.
This was a pretty bad one when it happened. I solved it by switching the affected tools to non-pango dependent alternatives.
I’m not too surprised they chose to double-down and mute the discussion. A lot of decisions like this is why the open desktop experience is a disaster.
This isn’t exclusive to GNOME, but the whole ecosystem suffers from it, e.g. PDF viewers: KDE’s Okular’s new smooth scroll “feature”, or mupdf’s “trim margins” feature request.
I’m surprised bitmap fonts survived for so long. They should have been removed from everything ages ago! The presence of this ancient technology is still causing unpleasant surprises sometimes.
As somebody who exclusively uses bitmap fonts (Misc Fixed in particular is my absolute favorite), this comment pains me.
Can you describe the OS, desktop environment, browser, text editor, IDE, etc. you’re using? I love bitmap fonts because of their enhanced clarity and design, but most software is unable to handle them properly. I have yet to find a setup that lets me use bitmap fonts across the board, from desktop environment all the way to the applications. SerenityOS seems to do really well on this front.
I’ve gotten almost everything to work with Misc Fixed, with the exception of Discord.
Even with BBD (Bandaged Better Discord) I still can’t get it to use the Misc Fixed font. -_-
Try using Ripcord https://cancel.fm/ripcord/ for Discord. It supports any font you like, and additionaly it’s a fully native Qt application, not an Electron crap.
Fonts more than many other things in normal graphics depends on the ‘context of use’ and what price you must pay versus the price you can tolerate paying. It’s your cycles and all that but the vector step is a big and pricey complexity leap – rough incremental cost (anything non-printer):
(arguably hershey vector font set kind of things fit in here somewhere, but mainly embedded use?)
I use most of that range daily, whenever possible though, bitmap for the win (and cycles).
The thing with that discussion though is like, while bitmap fonts may have some space optimization weirdness that makes parsing a little bit of work, for what they are, it doesn’t register on the complexity scale. Heck, those fun emojis are embedded PNGs forcing both bitmap management and pixel-scaling to be there anyhow..
Given two particular names in that thread, I’d go with ‘obstinate’..
I couldn’t actually read this submission as Gitlab was too much for my current internet connection, but I didn’t like this at all. I wouldn’t have had a huge problem with it except for the fact that by default I find scalable fonts to be very unreadable on non-high-resolution screens.
This might just be personal opinion, and since getting a HD display it hasn’t been an issue for me, but I do wonder whether it was another case of the developers having better-than-average (or even better than the lowest reasonable) devices and dismissing anyone in a different situation.
Accessibility, ha.
IMHO this is about a small minority opting into choosing an outdated technology (bitmap fonts) with serious limitations but advantages on their specific use-case and then blaming the developers for breaking their workflow.
Bitmap fonts stopped being universally useful with the decline of dot-matrix printers in the late 80ies, about 40 years ago and their usefulness gradually declined over the years as we got higher resolution displays, Unicode and lately very high resolution displays meant to run at 2x.
People still preferring bitmap fonts do not want to print them, have 1x monitors and use nothing but English. And they want maintainers to continue to support 40 years old technology in addition to all the new requirements around font rendering for the fonts that everybody uses because it’s convenient for them.
No machine made in the last ~35 years is too weak to handle vector fonts. In this instance, the argument about developers running too powerful hardware really doesn’t count any more
No one said “too powerful”; the relevant question is whether developers buy fancy new hidpi displays and forget about the many users who are happy to stay on older displays with lower resolution where bitmap fonts look better.
that is in the eye of the beholder (ever since anti-aliasing has become possible I personally preferred vector fonts - and the vast majority of users seem to agree considering the prevalence of bitmap fonts these days) and even disregarding the HiDpi support, the vector fonts still have other advantages (like being printable. or having unicode support).
Besides, bitmap shapes are still supported - if they are inside of an OpenType container. So a conversion of the existing fonts should totally be possible for those cases where going to a technology invented 40 years ago and widely adopted has too many drawbacks for a specific user.
In my original comment I said I wouldn’t have minded except the new system looked ugly to me by default. As far as I can tell I didn’t say anything that my opinion was fact or the only right way.
You keep coming back to printability and unicode. Printing totally confuses me as when I used bitmap fonts I printed with them. I’d like to clarify with unicode - are you talking about composable glyphs? I’ve had success using bitmap fonts with CJK characters, but I can assume they wouldn’t work as well with something like
t҉h߫i͛s͕.The amount of characters which would need to be created is way too big for bitmap fonts where each size would need its glyphs to be manually created and opimized. Thus the amount of available bitmap fonts with reasonable amount of unicode characters is relatively small (in-act, I only know of GNU Unifont which also only contains 5 sizes and still weighs in at 9MB)