Hacker News Reader

Comment by GMoromisato | Hacker News Reader

What I wish for is rather than encoding the wavy imperfections in the font, they should be procedurally generated at rasterization time. This way, the graininess can stay at the same resolution regardless of the font-size. As it is now, if you have a 120pt font, the rough edges are magnified.

Is there a way to specify something like that in the font language? Or does the rasterization engine have to implement that?

View on HN

I was already writing a comment about procedural generation before I saw yours. I was thinking about placing shapes on the boundary of a basic character shape, and placing random points within those shapes which then have lines/splines drawn between them. You could change the size of the shape depending on how much you want the shape to vary. That way you can still exercise control over what specific features are preserved. I'm sure someone can come up with something better.

Anything procedurally generated is antithetical to professional font design. Fonts at different sizes are carefully fine-tuned exactly for the reasons that you mentioned, i.e., small features at larger sizes start looking wrong.

In this case, the digitized font is taken not from the metal types themselves, but from specimens printed on paper. The paper was less uniform and smooth than modern paper, and there was a noticable amount of ink bleed. Since OP is interested in the "character" given to the letterforms by this era of printing technology, it makes sense to suggest some way of simulating this uneven bleed and spread.

Usually, yes, but this font tries to reproduce the imperfections of text printed centuries ago (or, to quote the article, "look badass with its kinks and nicks"), so having two glyphs of the same type look exactly identical feels a bit jarring. Same as with other "rough" fonts which try to emulate stencils, handwriting etc. All of these would benefit from some randomness...

so how do SVG fonts handle this? Or do they?

on edit: asking as you probably have in depth technical knowledge on this it would be nice to get some pointers on.

There used to be. In ‘Type 3’ fonts, each glyph is defined by a Postscript routine. They were not supported by any of the major display systems (Windows, Mac, X). Maybe NeWS or NeXT did; I don't know.

Yeah, I was idly wondering if it might be fun to try rendering fonts through a basic physics simulation of inks and paper types. It would probably be wasteful to do most of the time in font rendering, but it might be fun to try when doing things like rendering final slides or PDFs (that are themselves not intended to be sent to printers, because that would be silly).

I wonder what the impact on energy expenditure would be for a widely used font.

Reply on news.ycombinator.com