Hi, :) :). Thanks for reading the 14th issue of this newsletter. This has been a busy, yet wonderful week for me. It wasn't perfect—I didn't get a lot done, or even advanced in my multi-issue quest to find a decent word processor. Great things happened regardless.
Creating is often the metric I judge the quality of my weeks by, but this one was a reminder that it's not all there is. That the depths of design and algorithm is not the only place I can look for beauty; and that I may find it in more formal and conventional things—in experiences and in people.
This issue is hopefully one-section-different from the last one. I've replaced the usual Experiment section with a few words about my experience with using bitmap fonts in the type-dense environment that terminals are. I haven't had the chance to dig something up for an Experiment section, and I'm hesitant to send yet another email with Dall-E generations. If you'd still like to see them, however; here's a link to all previous issues of this newsletter. Maybe it's time that refuse.ink gets a newsletter archive page of its own?
❤️, Yash.
|
|
A thing I often wonder about is how differently digital typography would have evolved had we re-thought type for digital displays instead of trying to emulate ink-type on grid-like screens. Throughout its history, typography has adjusted to its media. This was also true for typography on early LCDs.
However, we got higher-resolution displays, more color depth, and better aliasing. This made it easier for us to render type as we already knew it on displays that were more like grids and less like paper. It's a beautiful set of techniques, but has its limitations.
Nearly everything is auto-aliased these days. It makes sense for most applications, but is likely not the best approach for repetitive and essential features like rendering text or small icons. These are more utilitarian than decorative; and letting almost-good sets of algorithms handle these tasks produces almost-good results. Auto-aliasing, for example, often creates unwanted artifacts when used on small icons or type. This is why website favicons (the little icon you see on your browser tabs) are often pixel-fit by hand, because software can't predict those details correctly.
Here's an example of a favicon I pixel-fit by hand for my website, refuse.ink:
|
|
This is also why type designers have to configure their typefaces to be hinted properly. In my opinion—while these technologies are necessary for some applications—they are largely used as solutions to a deeper, ignored problem.
I have spent the last few weeks configuring a lightweight Arch Linux installation to work as I would like it to. By default, most things in Arch are done using the terminal. By default, it uses a bitmap font. I found it far more legible and comfortable to read as soon as I saw it, and decided to configure dwm, a window manager I use, to also use (a different) bitmap typeface. It's extremely crisp and legible even at tiny sizes; which also makes it screen-efficient and terminal-friendly:
|
|
|
I also decided to use a bitmap image as my wallpaper for this system, which I created with Blender and Processing (for dithering):
|
|
LOOKING FOR WORD PROCESSORS
|
|
I don't yet have any substantial updates on the word processor situation, but I ran into a small change in opinion while struggling to free my computer's primary storage drive. I noticed that one of the few word processors I thought performed well—MarkText—was actually using hundreds of megabytes in storage on Windows.
This was also the case with a few more word processors I've been testing, but I remember MarkText because it was one of the most usable word processors I had been looking at.
A few hundred megabytes of storage is not a huge cost on modern machines; however, it is wasteful, and impacts performance for programs that could easily have functioned the same way (if not better) without 99% of their unused garbage code. Most programs should run instantaneously on modern hardware. Yet, they don't. Writing on a decent text editor should not take as much computing power as it often does.
|
|
|
Direction works over time.
|
|
|
|
|
