Online monobit is not working?

[hackerb9]

I believe https://robhagemans.github.io/monobit/ is supposed to show images of the bitmaps. Unfortunately, it appears to no longer do so, at least with the browsers I tested. The list of fonts shows up, but nothing is clickable.

[robhagemans]

Thanks for flagging, I see it too.

I made no recent changes to the page, so there's a few hypotheses I can come up with:

• a font was added that triggers a bug in the code
• the page has hit a download limit on GitHub
• some part of the code was broken by browser or library upgrades

Will need to investigate

[hackerb9]

I checked the wayback machine and it looks the same. Is the JavaScript relying on some service from GitHub that isn't mirrorable? If so, maybe now would be a good time to make sure the site falls back to a resource that can be archived for posterity. (Think of the generations of bitmap font hoarders to come!) 😊

[inexorabletash]

Seems like the error is happening server-side, and being relayed to the client. Console spew:

retrieving /repo/saa5050-semigraphics-noncontiguous.yaff
app.js:174 Error rendering teletext/saa5050-semigraphics-noncontiguous.yaff
app.js:175 Traceback (most recent call last):
Traceback (most recent call last):
  File "/lib/python3.10/site-packages/monobit/render/renderer.py", line 23, in <module>
    from arabic_reshaper import reshape
ModuleNotFoundError: No module named 'arabic_reshaper'

Note that this is followed by this longer spew:

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/lib/python3.10/_pyodide/_base.py", line 460, in eval_code
    .run(globals, locals)
  File "/lib/python3.10/_pyodide/_base.py", line 306, in run
    coroutine = eval(self.code, globals, locals)
  File "<exec>", line 2, in <module>
  File "/lib/python3.10/site-packages/monobit/__init__.py", line 14, in <module>
    from .storage import load, save, loaders, savers
  File "/lib/python3.10/site-packages/monobit/storage/__init__.py", line 17, in <module>
    from . import fontformats as _fontformats
  File "/lib/python3.10/site-packages/monobit/storage/fontformats/__init__.py", line 9, in <module>
    import_all(__name__)
  File "/lib/python3.10/site-packages/monobit/base/imports.py", line 18, in import_all
    vars(module).update({
  File "/lib/python3.10/site-packages/monobit/base/imports.py", line 19, in <dictcomp>
    Path(_file).stem: import_module(
  File "/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/lib/python3.10/site-packages/monobit/storage/fontformats/amiga.py", line 19, in <module>
    from monobit.render import RGBTable, create_gradient
  File "/lib/python3.10/site-packages/monobit/render/__init__.py", line 8, in <module>
    from .renderer import render
  File "/lib/python3.10/site-packages/monobit/render/renderer.py", line 25, in <module>
    logging.debug('Could not import module `arabic_reshaper`: %s', e)
NameError: name 'e' is not defined

... but that's just because except Exception: should be except Exception as e: in monobit/render/renderer.py

[hackerb9]

Online monobit is still offline. I needed a quick page to check fonts so I made an ugly kludge of a static page which you can see here: https://hackerb9.github.io/hoard-of-bitfonts/images/

It works well enough for my purposes, but @robhagemans, I may have uncovered some bugs in the hoard that you may want to know about:

• Some fonts did not want to render in a reasonable amount of time with monobit-convert. (e.g., SuperPET APL) and had to be left out,
• Some gave peculiar error messages (monobit-convert fails trying to write to any directory with a period in its name, such as images/amiga/workbench-3.1/)
• One font had extra wide spacing: |Custom|/amiga/nudelfonts/PolarSmall-Prop is 3167 × 55 pixels.
• Others had huge vertical gaps that I presume represent Unicode ranges with no data. (E.g., figlet-banner and PDP1-1964. (191 × 2207 pixels)
• And at least one had different glyphs which were assigned the same code point and thus never rendered. See codepoint 112 at the end of this file: PDP1-1961-codeword.yaff. (It also replaced the letter "p" with a weird half-heart thing.)

Are those known and expected behaviour?

[robhagemans]

Hi, thanks for reporting these issues. I don't know when I'll be able to look into this further, but a few of these I can address here:

• Some fonts did not want to render in a reasonable amount of time with monobit-convert. (e.g., SuperPET APL) and had to be left out,

I expect this is due to trying to generate an image of the whole unicode range, see other issue below.

• Some gave peculiar error messages (monobit-convert fails trying to write to any directory with a period in its name, such as images/amiga/workbench-3.1/)

Thanks, this is a known issue, monobit tries to use anything after the dot as an extension to determine the output or container format (so if I save a png format to a filename ending in .zip it creates a zip archive with the pngs in it). It may be possible to avoid the issue by explicitly setting -format=png -container-format=dir or by specifying the full output filename. Not sure if that works though.

• One font had extra wide spacing: |Custom|/amiga/nudelfonts/PolarSmall-Prop is 3167 × 55 pixels.

Thanks, likely some conversion error, possibly we use a data field in the original file that the Amiga ignores. Requires investigation of the Amiga file.

• 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. IIRC there's a setting to make it use position value rather than codepoint, but I don't recall which it was.

• And at least one had different glyphs which were assigned the same code point and thus never rendered. See codepoint 112 at the end of this file: PDP1-1961-codeword.yaff. (It also replaced the letter "p" with a weird half-heart thing.)

Yeah that's wrong, checking the original html it marks various symbols with tags like p_spc which have then all be mapped onto the lowercase p codepoint. I may have used some throwaway script to convert the html source. Probably best fixed manually.

[hackerb9]

Hi, thanks for reporting these issues. I don't know when I'll be able to look into this further [....]

Thanks. Now that I know which are bugs, I'll file separate issues.