flowchartsman / greybeard Goto Github PK

a chunky monospaced bitmap programming font for old nerds that hate eyestrain

License: Other

Makefile 51.56% Perl 32.53% Roff 15.42% Shell 0.49%

greybeard's Introduction

Greybeard is a chunky monospaced bitmap programming font for all you pixel-perfect nerds who don't like eyestrain. It's mostly a vector port of UW ttyp0 with a few tweaks.

It covers most of the Latin and Cyrillic alphabet, Greek, Armenian, Georgian (only Mkhedruli), Hebrew (without cantillation marks), Thai, most of IPA (but no UPA), standard punctuation, common symbols, some mathematics, line graphics and a few dingbats (about 3000 Unicode characters).

It is provided as rendered outline fonts in the following pixel sizes: 11, 12, 13, 14, 15, 16, 17, 18 and 22. Each of these has a bold variant, and italic variants are provided in 15, 16, 17 and 18. Additionally, all fonts with an italic variant have an experimental auto-generated bold-italic variant, though mileage with these may vary.

It is named after those mythical sysops, staring at white on blue Borland compilers late into the night. Some say they stare still...

Samples

Installation

Font files can be downloaded from the releases page

Usage

Greybeard is split into multiple separate fonts named with the point size they are intended to be rendered at for pixel-perfect display. To use it, install the variant you like, and then set the font size of your editor or terminal to match. For example, if you like the 18px size, install Greybeard-18px*.ttf and set the size to 18pt in your application. Because of the way the outlines are generated, multiples should work as well.

For code editors you may need to set an explicit line height as well, to keep the spacing sane. For example, setting the line height to around 1 in VSCode seems to work well.

The reason the font is split up into different sizes is because Windows kind of a jerk about bitmap fonts. In theory, .ttf does support embedding bitmap versions of various point sizes (a feature called bitmap strikes), but Windows has decided to ignore this except in very specific, fiddly cases), which have the side effect of making the font useless in the terminal. This is unacceptable for this font, so here we are. If you know of way around this limitation, please comment in the ongoing issue and maybe send a PR my way.

Relation to UW ttyp0

Most of the work towards Greybeard has been in assembling a toolkit to convert the original bitmap font, UW ttyp0, to a modern outline format and trying to make sure it renders crisply. The actual glyphs are still almost entirely the work of Uwe Waldmann, the original creator of UW ttyp0. There have been a few tweaks, and will likely be a few more as the project progresses, but we wouldn't have such a comprehensive bitmap font without all of Uwe's hard work. The reason it has a different name is pretty simple: the MIT Licence that UW ttyp0 uses stipulates an additional clause that any changes that add or alter glyphs should cause the font to be renamed in such a way to dissasociate it from the original author. This makes sense, since no one wants to get spammed with support requests or complaints for something they didn't write. By giving it a completely different name, I hope to avoid this. Also "Greybeard" is a fun name. So, yeah. Any issues should target this project.

The following is a brief list of differences from UW ttyp0:

Render nbsp as normal space to avoid rendering glyphs in editor whitespace.
Default to straight apostrophe/graves.
Default to slashed zero.
Default to centered tilde.
Fixed # glyph for certain sizes/weights to make it less "pointy".
Bold-Italic variants.
Additional height properties to help .ttf generation.

Building

If you want to build the font yourself for testing or if you want to select stylistic variants, you can use the dockerized build process which uses the bitmap-font-vector-build container I created to collect all of the necessary tools in one place. Just make whatever changes you like and run ./scripts/docker_build.sh, which will generate .ttf files in font_out. You can also specify any make target you like with this script. The ones that probably interest you are:

ttfs
woff2s
pcfs

Note: the woff2s target will also generate the .ttf files, since it creates the .woff2 files from them.

Mostly you will probably only want to modify build/VARIANTS.dat and rebuild the font.

Repo Layout

The tree under /build is more or less the same layout as the original repo, and is used to build the intermediate .bdf files which then generate both the .ttf and .pcf files. The intermediate .bdf files are in turn created by applying the settings in build/VARIANTS.dat to the files in build/bdf, which serve as the source of truth for the font.

Manual instructions in build/INSTALL are kept around for legacy purposes and are geared towards generating and installing a gzipped pcf font, so they are probably not useful to anyone these days. If you're installing the font in an environment that supports it, you probably know what you're doing.

Reporting Issues

Most testing is done on MacOS, so there aren't a lot of eyes on Windows and Linux. Please file an issue if you have problems with usage and/or rendering on any platform.

greybeard's People

Contributors

Stargazers

Watchers

Forkers

andresdev5 volbot

greybeard's Issues

Move /build to separate/archived repo.

Given that we're unlikely to need the non-unicode encodings ever again, and since most tools have difficulties making sense of the unmangled BDFs, it's probably best to move the /build directory out of the respository altogether and standardize on the built gb-X-uni files as source of truth moving forward.

Embedded bitmap strikes research.

One of the reasons Greybeard no longer provides a single .ttf is because bitmap strikes don't seem to be a viable option in the modern era. Therefore I switched from using fontforge to using Bits'N'Picas to synthesize the font as pseudo-pixel outlines. This works great, and seems to do a lot of inspection on the BDF to get things right, but now each size has to be its own font.

This was considered a worthwhile tradeoff for the convenience of automatic building, plus it makes it much more clear what size the font is intended to be used at, instead of providing list of "good point sizes" and "bad point sizes". That said, it would be nice to have them all in one file again.

mkttf attempts to automate this using the trick of adding CKJ glyphs and setting the codepage to trick Windows into actually rendering bitmap strikes, however it's unclear if this is viable for usage on Windows, given the issues described in the link above.

If you have experience making Windows do the right thing with fonts that have bitmap strikes, please comment here or issue a PR!

.ttf files don't seem to work in windows

Perhaps related to one or more of the following:

Create BDF preprocessor tool.

As part of the work for #10 #11 and #6, a new tool will need to be developed to operate on the unicode BDF files and provide the functionality of build/VARIANTS.dat as well as selective glyph removal and maybe even porting mkbold code over for the synthetic bolditalic variants to allow for glyph expansion and kerning when bold glyphs are too large.

Bold+Italic variant?

First, wanted to say thanks for making such a great font! I've been using it for the past six months and love it. Having standard, bold, and italic variants really makes it stand out (and much more useful as a result) among the other bitmap fonts I've come across.

Would you consider making a bold+italic font variant?

The three variants provided currently cover 95% of my use cases, but with kitty's font config I do run into occasional cases where the bold_italic_font is expected and I have to use a fallback. Having a bold+italic for Greybeard would really complete this font and make it usable across all applications I need.

Thanks! Feel free to close if it's not something you're interested in (or if it's not possible to do with the design of the font at its current sizes).

Cut v1.0 and move to release artifacts.

Checking out font files in a repo or manually downloading them from Github is old and busted. Github actions on release tags are the new hotness. To wit, I am planning a 1.0 "release" that will integrate this, removing all of the files in /dist from the repo itself.

This will dovetail with a github.io page.

woff/2 support

Consider woff/woff2 for web use. Shouldn't be too difficult with a little Makefile/Docker magic.

Add option to eliminate whitespace glyphs.

Whilst attempting to use Greybeard in a keynote presentation, I noticed the linefeed glyph appeared wherever I hit shift-enter to manually split a line (i.e. a particularly long bulleted list item running into an image). This is common enough that this glyph should be optional, and the default should be not to show them.

This applies to the following glyphs:

CtlHT: horizontal tab
CtlLF: line feed
CtlVT: vertical tab
CtlFF: form feed
CtlCR: carriage return
CtlNL: newline

The normal precedent for feature selection is to edit the VARIANTS.dat file originally provided by UW ttyp0, which is what is done to avoid the display of non-breaking space by simply copying the ordinary space glyph in its place:

# build/VARIANTS.dat
COPYTO Space SpaceNoBreak

This won't work here since these characters should be zero width. Furthermore the original distribution's bdfmangle tool, which is used to parse and execute the changes in VARIANTS.dat, does not have a verb to delete or omit glyphs, so one will have to be added or a new tool will have to be written.

It's likely going to have to be a new tool so that I don't have to write Perl, and also to help out with the work that needs to be done for #6

Fixup synthetic BoldItalic variants.

Thanks to #5 Greybeard now has synthesized BoldItalic variants generated from the italic strikes using mkbold-mkitalic. Unfortunately, the algorithm does not take bounding boxes into account, so anywhere a thickened glyph would run over the edge (usually by a single pixel), it simply cuts off. This isn't too bad, but it's bothering me. I'm sure there's a way to expand the bounding boxes dynamically and to use the bdf analogue of kerning to account for it, but it requires some investigation and, likely, digging into the annals of old xfont utilities.

Needs automated ttf/dfont build.

Currently done manually from fontforge files.

Differences between Ttyp0

I tried the font out, but didn't find any differences between Ttyp0, there is any?

Create a github.io page for 1.0 release.

Along with the planned changes for #7 , the project should probably have a github.io page, since the final product are font files to be downloaded. Integrating releases with a github.io page is a no-brainer, but now of course I have to learn about how all that stuff works, since I've never done it before 😬.