Amusingly, here it is also BitMap [1]. Why they use an obsolete noncompressed proprietary format instead of PNG I don't know.

Edit: looks like it's because BMP supports 1-bit packed pixels and ~~PNG doesn't~~ (Edit to edit: this is wrong). The file sizes are almost identical; the 8x difference in the number of bits is exactly balanced by PNG compression! On the other hand, PBM [2] would've been a properly Unixy format, and trivial to decode, but I guess "the browser knows how to render it" is a pretty good argument for BMP. macOS Preview, BTW, supports all the NetPBM formats, which I did not expect.

[1] eg. https://unifoundry.com/pub/unifont/unifont-17.0.03/unifont-1...

[2] https://en.wikipedia.org/wiki/Netpbm

Maybe they set everything up before png was popular and never changed the workflow since then (or didn't care about the website to adjust anything)? After all, the PNG is only about 2 years younger than the font

That's plausible. Or maybe they just liked the BMP vs. BMP coincidence.

> Edit: looks like it's because BMP supports 1-bit packed pixels and PNG doesn't. The file sizes are almost identical

That's nonsense, PNG supports 1-bit pixels just fine, and the resulting file is a lot smaller (when using ImageMagick):

    $ file unifont-17.0.03.bmp 
    unifont-17.0.03.bmp: PC bitmap, Windows 3.x format, 4128 x 4160 x 1, image size 2146560, resolution 4724 x 4724 px/m, 2 important colors, cbSize 2146622, bits offset 62
    $ magick unifont-17.0.03.bmp unifont-17.0.03.png
    $ file unifont-17.0.03.png 
    unifont-17.0.03.png: PNG image data, 4128 x 4160, 1-bit grayscale, non-interlaced
    $ wc -c unifont-17.0.03.*
    2146622 unifont-17.0.03.bmp
     878350 unifont-17.0.03.png
    3024972 total

Thanks! I definitely should've double-checked. Apparently it was just the image viewer that didn't bother converting the 1-bit BMP to 1-bit PNG.