monobit tries to generate an image of the whole unicode range

[hackerb9]

Others had huge vertical gaps that I presume represent Unicode ranges with no data. (E.g., figlet-banner and PDP1-1964. (191 × 2207 pixels)

That's expected behaviour, image conversion uses code points to determine position in the image. That's often the most intuitive (leaving undefined entries in the chart blank) but works out badly for Unicode fonts that span very different code points.

I gently suggest that it might be better if monobit-convert removed empty rows by default.

IIRC there's a setting to make it use position value rather than codepoint, but I don't recall which it was.

I couldn't find it in --help. An option to layout the characters in font position order would not solve the problem for all fonts. For example, one of my favorite bitmap fonts, neep-10x20, uses ISO-10646 for position numbering and includes both U+0000 (NULL) and U+FFFD (� REPLACEMENT CHARACTER), so monobit-convert would still create an image 43,000 pixels high.

I notice that converting neep.yaff to a PDF created only 20 pages. (At 256 glyphs per page, it would have been 256 pages if monobit didn't compact the output.)