How to convert .ttf to .fnt for use with M10_SCR.COM DOS font driver

Question

I have a DOS program M10_SCR.COM that loads as a TSR and allows the use of fonts. It works with its own basic built-in fonts, so now I am trying to convert .ttf fonts into .fnt so I have more fonts to choose from.

There are instructions on how to convert .ttf to .fnt with FontForge at StackOverflow:
How to convert TTF to FNT with Fontforge

I did successfully convert a .ttf font to .fnt, but it fails to load with M10_SCR. There are many options in FontForge that may be the cause of failure.

When running M10_SCR.COM with the converted font, it gives:

Error - wrong external font file size!

To troubleshoot, I tried loading one of M10_SCR's built-in fonts into FontForge. It gives these errors:

[dialog box: Bad magic number]
This does not appear to be a Windows FNT or FON file
[dialog box: Couldn't open font]
8x16FONT.FNT is not a known format (or uses features of that format fontforge does not support, or is so badly corrupted as to be unreadable)

I can't find any .fnt fonts on the Internet to try with M10_SCR for troubleshooting.

Why wouldn't a converted font work? How can I find out what the difference is? How can I get this to work?

Answer 1

This is Morozov’s screen driver, available e.g. from SimtelNet archives. It uses a fairly typical font format for EGA/VGA fonts, namely a dump of the in-memory font data as loaded for the character generator in an EGA or VGA graphics adapter: 256 characters each formed of 8 to 16 bytes (depending on the number of lines in the font), each byte encoding a line of a character — so the font files’ size is always a multiple of 256, 2048 bytes for small fonts (as used in 80×50 mode on VGA), 3584 bytes for 14-line EGA fonts, 4096 bytes for 16-line VGA fonts... This doesn’t match any of the .FNT formats available in other environments, such as Windows. I’m not sure whether there are any conversion tools available to produce appropriate fonts from TrueType fonts or other such formats; I don’t remember there being any in the 90s.

Fonts for tools such as this were usually hand-drawn using dedicated font editing tools such as Michael J. Mefford’s FONTEDIT (originally published in PC Magazine, later released as shareware), or Oliver Fromme’s CAFE (my two personal favourites, which are unfortunately hard to get a hold of nowadays). You’ll find a number of fonts to try out, and font editing tools, in SimtelNet’s “screen” directory; look through the index for details. I wrote a font-loading tool which supports a variety of formats, loadfont, although since it’s not a TSR it’s not as versatile as Morozov’s screen driver.

You can convert bitmap fonts in a variety of formats (including Windows .FON and .FNT) to raw fonts using PSF Tools, which are designed around the PSF format commonly used for Linux console fonts. That provides access to a wide variety of font collections, and would solve your problem if TTF fonts can be rasterised to bitmap fonts.

Answer 2

I suspect that what you're dealing with here is two different file formats that happen to use the same filename extension, of ".fnt". There has never been any mechanism to control the use of filename extensions on DOS or Windows, except for market pressure, and .fnt is a very obvious choice for fonts.

• Windows .fnt is pretty much obsolete, but it could contain vector or raster glyphs.

• Metagraphics .fnt is a bitmap format that certainly isn't the same as the Windows format, and probably isn't the one used by M10_SCR, since it seems designed for fonts of higher resolution than MS-DOS INT10 usually deals with.

• M10_SCR [.fnt] seems to be something else.

I can't find much about M10_SCR on the net, but it's a minimum of 22 years old, quite possibly considerably older. Windows' use of particular filename extensions wasn't considered significant by many DOS programmers in the late eighties and early nineties, since Windows didn't have much market share until the advent of Windows 3.0 in 1990, and didn't become dominant in the PC market until the mid-nineties.