Go: proposal: golang.org/x/image/font/inconsolata package

[nigeltao]

The golang.org/x/image/font/... packages should provide a "batteries included" bitmap font, so that simple Go programs can draw some text easily without having to find (and depend on) both a "third party" font library (i.e. Go's freetype, which uses the Freetype license, so it can't be in the stdlib or golang.org/x) and third party font files (whose location and availability are OS-dependent at best).

Currently, that default font is based on the classic X11 fixed font, in the public domain. It's essentially a 1 bit per pixel font, even though Go's image.Alpha format for glyphs is 8bpp. It's also not the prettiest font.

I propose to pre-render a bitmap version of the Inconsolata font, and provide it as a package of Go source code, that would work with standard Go tools like "go get". The package path would be golang.org/x/image/font/inconsolata. This would export two variables, which users would refer to as inconsolata.Regular8x16 and inconsolata.Bold8x16, which implement the font.Face interface from golang.org/x/image/font.

That Go source code version of the Inconsolata bitmap data would be licensed the same as the rest of the Go standard library: https://golang.org/LICENSE. This is a different license than the SIL Open Font License that Inconsolata was released under. However, the fonts are copyright Raph Levien (who is employed by Google) and Cyreal, both have signed the CLA, and both approve of this specific "package inconsolata" Go source code proposal.

Inconsolata's home page is at http://www.levien.com/type/myfonts/inconsolata.html

[mirtchovski]

Ability to license under Go's terms notwithstanding, I would like to throw another font as a possible replacement: Hack (https://github.com/chrissimpkins/Hack).

I spent a lot of time pre-rendering ttf fonts for the Plan 9 display subsystem (http://mirtchovski.com/p9/fonts/), i think i have plenty of experience with such fonts and, at least, the acme/rio display programs... For me Hack is a clear winner, inconsolata isn't as clear in the "Il1" space.

that said, inconsolata is not a bad font and if you can get it with the license you desire that may trump all other suggestions.

[nigeltao]

I have the license for Inconsolata that I desire.

[gopherbot]

CL https://golang.org/cl/24482 mentions this issue.

[dskinner]

This seems at ends from what I'd expect of an x/font library. I'm very much for "batteries included", but a single font at a single size with undesirable pixelation in either sizable direction? For a TTF? Is the size difference between embedding the TTF and prerendering the glyphs really that big of a difference?

Edit: more simply, the rationale for pre-rendering vs embedding-the-TTF isn't given in the proposal.

[bsiegert]

The rationale has in fact been given: to render the TTF, you need the Go Freetype library. The library is under the Freetype license, which is more restrictive, thus it cannot be part of the standard library or /x/ packages.

[davelab6]

Ability to license under Go's terms notwithstanding

Sadly the Hack licensing is very messy

[adg]

I'm in favor of this proposal.

[driusan]

I'm not a huge fan of this proposal because it has the same problem as x/image/font/basicfont: It's only one non-standard font in a fixed font-size, with no obvious way to get variations (why regular and bold? Why not oblique? Or BoldOblique? Etc)

Freetype not being in the standard lib notwithstanding, it would be more useful to me to have a package that queries the system for what fonts are available, or all fonts that are available with a certain property (bold, italic, font family, font name,etc) perhaps with some helpers to get things like the default system monospace font or the default system sans serif font. Users would still need to import the freetype package to parse the file, but they need to do that in any other programming language too, and simply querying the OS font database shouldn't have any licensing problems.

[adg]

@driusan

"Freetype not being in the standard lib notwithstanding"

This misses the point entirely. This proposal is to provide a better basic font for programmers who cannot (for whatever reason) use freetype. If you can use freetype, you can use whatever true type font you want.

[driusan]

@adg I don't believe it does. Part of the stated reason for this is to not depend on "third party font files (whose location and availability are OS-dependent at best)." This doesn't address that issue, it only includes a different third party pre-rendered font face in the standard package.

basicfont already covers the use case that you mention (not being able to use freetype or perhaps any font files at all)--so unless inconsolata covers a wider range of unicode, this is only a prettier font with the same purpose, and my objection is that arbitrarily adding single font faces is a slippery slope. If you're unable to use freetype but need something better than basicfont, there's no reason to assume that this face will cover your needs either, since it has the same limitations as basicfont (other than being 8bpp, but I don't think that's the limitation stopping basicfont from being useful--it's having different sizes or style variations which make people need to go elsewhere. )

If someone objects to freetype on licensing or other grounds but needs something better than basicfont, there's already x/image/font/plan9font to parse a different (more open, less common?) font file format.

[jimmyfrasche]

Regardless, I assume you wrote some program to pre-render and embed the font into a package.

I imagine it's not super complicated, but publishing that separately, even if unofficially (and even if it'd take some community effort to generalize it), would let anyone package up whatever default font/sizes they required.

That seems like it would be useful in itself. (In favor of this proposal, ftr).

[crawshaw]

@driusan I don't think this package is trying to solve any of the problems you describe, it's just a slightly prettier implementation of basicfont. It is useful for the same set of tasks: tests and small examples with no dependencies outside golang.org/x.

In fact, now we have this I'd like to see basicfont deleted.

[driusan]

@crawshaw I know it isn't, that's my point. It's a second package with the same use case, benefits and limitations as an existing package. Having two packages with the same purpose is confusing, especially when the "right" one to use has the less intuitive name.

Removing basicfont would solve my objection, but if it's really just a prettier font why not just update the face (and documentation) in the existing package so that users get upgraded transparently? (Especially since the package in question is still under x/, and it's easier for a new user to tell what a package named basicfont is for than a package named inconsolata)

[nigeltao]

@jimmyfrasche that program is https://github.com/golang/freetype/blob/master/example/genbasicfont/main.go

[nigeltao]

@driusan @crawshaw

Yes, golang.org/x/image/font/plan9font already exists, and it's under golang.org/x, but it has the same problem in that you still need to provide one or more font files separately. The whole point, as crawshaw said, is for tests and small examples where you just want the simplicity of a single import and no further runtime dependencies. This proposed package does not replace freetype; if you want freetype, you can have freetype. But sometimes you don't want freetype's complications.

I will distinguish between basicfont.Face, the type, and basicfont.Face7x13, a value of that type based on the X11 fixed font. You can think of the proposed inconsolata.Regular8x16 as a better (nicer looking, wider unicode coverage) basicfont.Face7x13, and I agree we could probably delete the latter if the former lands. I don't think we can delete the basicfont package entirely, because others may want to use the Face type, especially given the genbasicfont program I just linked to.

As for being basicfont.Face8x16 or basicfont.InconsolataRegular8x16 instead of inconsolata.Regular8x16, at some point we are bikeshedding but I prefer inconsolata.Regular8x16. Note that it can't be a transparent re-purposing of the existing basicfont.Face7x13 name because the metrics are different (8x16 instead of 7x13), plus there's now regular and bold flavors.

A package to query what fonts the OS provides would indeed be useful, but if, in practice, you're querying for TTF fonts, then your program will pretty much need to depend on freetype, so such a package probably doesn't belong under golang.org/x. It could possibly be a new package under github.com/golang/freetype/... but that's a separate discussion.

[mortdeus]

You guys aren't ready to enter the bizarro world that is font licensing.

You can't license or trademark the actual font face graphics. You can only license the actual underlying software implementation of the font face.

http://blog.crowdspring.com/2011/03/font-law-licensing/

[minux]

Using golang/freetype might not work with the license constraints, but
could we use the freetype package to generate a Go package that renders the
given font at any desired dimension? That is, we convert the glyphs and
hinting in ttf/otf into a Go package. I'd certainly want such a converter
program for some of my projects.

Also, have you considered the freely available Hershey vector fonts?

[nigeltao]

@minux: It should be straightforward, technically, to generate a Go package with the (scalable) vector data, and we could write a vector rasterizer under golang.org/x instead of github.com/golang/freetype.

Hinting is more difficult, as _using_ the hinting data as is requires implementing a TrueType bytecode VM, and the Freetype VM implementation has cases where reality diverges from the spec (e.g. https://github.com/golang/freetype/commit/a31d0146).

I haven't considered the Hershey fonts for this proposal. I'll keep them in mind for future proposals, although they were designed for vector output (plotters) rather than raster output.