search

robhagemans / monobit

Tools for working with monochrome bitmap fonts
MIT License
207 stars 11 forks source link

Converting `ter-132n.psf.gz` to PNG leads to infinite loop and RAM consuption #35

Closed malespiaut closed 1 month ago

malespiaut commented 2 months ago

Hello,

I ran the command monobit-convert /usr/share/kbd/consolefonts/ter-132n.psf.gz to ~/ter-132n.png which ran my CPU hot until no more RAM was available.

I ran this command on Arch Linux using the latest git revision of Monobit.

ter-132n.psf.gz

Best regards.

robhagemans commented 2 months ago

I think it's not an infinite loop, it's just trying to generate an immensely large image. There's something odd going on with the Unicode conversion from the PSF file, some of the characters come through as multiple-codepoint sequences while I don't think they should be. And the image generator tries to generate a table with each glyph in its proper position given the codepoint, which it'll interpret as UTF-32, so this becomes a very large table. All of which is not great so we probably need some different defaults for image generation anyway.

Meanehile you can work around the issue by replacing the unicode labels, like so:

./convert.py ~/Downloads/ter-132n.psf.gz label -char-from -overwrite label -codepoint-from=0- to ter.png
robhagemans commented 2 months ago

As to the first item, it looks like ter-132n.psf has an incorrect Unicode table: it has multiple alternative codepoints stored without separators, which means they get interpreted as a single grapheme sequence rather than as a list of alternative representations.

To the second point, I'm working on the image/chart representation and I'll probably add an option to output the glyphs directly by their position in the font, rather than in a grid position determined by their codepoint. The latter become unwieldy when the codepoints get too large, as this font shows...

robhagemans commented 2 months ago

I've uploaded monobit v0.46.0 - by default image output should now just have consecutive glyphs so the issue would not come up.

I still wonder about the incorrect (AFAICS per the psf spec) encoding in this sample file - as I think this is a standard font file supplied with many Linux distros. I wonder if kbd/the terminal emulator interpret these incorrectly by default (in which case we should expect more .psf files to follow this scheme)

robhagemans commented 1 month ago

Assuming the update has resolved the issue so closing, please reopen if this still occurs