Publish BDF fonts as crates

[rfuest]

It would be useful to distribute some BDF fonts as Rust crates to make them easily usable without having to manually add BDF files to a project. Having dedicated font crates, instead of adding some fonts to eg-bdf, has the advantage that the crates can be licensed using the same license as the BDF font.

Open questions:

• How can glyph subsets be handled?
• Should we publish one crate per font family or package multiple fonts with the same license in one crate?

[jamwaffles]

How can glyph subsets be handled?

Cargo features? Submodule exports like in e-g? Submodule exports might be better as they're a bit easier to pick and choose over cargo features. They're also symmetrical with e-g's API at time of writing, but that shouldn't be a hard requirement.

Should we publish one crate per font family or package multiple fonts with the same license in one crate?

There are probably compromises to be made however we do this. I haven't looked too closely at the BDF collections out there, but maybe collections like x11 are a good idea, but also for fonts with multiple variants and/or sizes available, release them under a single crate (see for example https://crates.io/crates/profont).

Some idle thinking: Would it be a good idea to provide some tooling that goes in build.rs to generate the required data files that the code needs to render with? The published crates with bundled, permissively licensed BDF files would use this build tooling internally, and users with specific font/licensing requirements can use exactly the same build tooling themselves. This would reduce code duplication, and let us get around licensing issues. Just an open thought at the moment, so please dismiss this paragraph if you had a better implementation idea in mind.

Also, would these crates be no_std?

[rfuest]

Cargo features? Submodule exports like in e-g? Submodule exports might be better as they're a bit easier to pick and choose over cargo features. They're also symmetrical with e-g's API at time of writing, but that shouldn't be a hard requirement.

Keeping the API similar would be a good idea, but I would also like to keep the flexibility the include_bdf macro provides. Perhaps we could add both, fixed glyph subsets like ascii and latin1 and another way to create custom subsets.

There are probably compromises to be made however we do this. I haven't looked too closely at the BDF collections out there, but maybe collections like x11 are a good idea, but also for fonts with multiple variants and/or sizes available, release them under a single crate (see for example https://crates.io/crates/profont).

The highest quality collection of BDF I could find are the xorg sources: https://gitlab.freedesktop.org/xorg/font The other collections, that we use in the tests, include some broken fonts but still provide a good overview of what is available.

I agree that different font sizes and weights should always be bundled in one crate, but I'm not sure about different fonts yet. The https://gitlab.freedesktop.org/xorg/font/adobe-75dpi repo, for example, includes multiple fonts. If we bundle all of them in a single crate the fonts might not be as discoverable as in separate eg-font-times and eg-font-helvetica repos.

Some idle thinking: Would it be a good idea to provide some tooling that goes in build.rs to generate the required data files that the code needs to render with? The published crates with bundled, permissively licensed BDF files would use this build tooling internally, and users with specific font/licensing requirements can use exactly the same build tooling themselves. This would reduce code duplication, and let us get around licensing issues. Just an open thought at the moment, so please dismiss this paragraph if you had a better implementation idea in mind.

That sounds like a good idea. I'm not planning to implement this soon, because I don't want to delay e-g 0.7 any further. But when I generate font crates, I'll try to make the tooling reusable.

Also, would these crates be no_std?

Yes, the generated crates will be no_std. This is easy to achieve, because the will only contain constants and no other code.