Does anyone have .fnt files for Angband?

[Magnate]

I'm pleased to say that Debian have accepted the revised version of the package which uses other fonts and does not depend on the .fon files. This gives us huge flexibility to use a wider range of fonts.

[Magnate]

That sounds great - I'm very happy to collaborate (though I know nothing about font management). The Debian packaging repo is at https://salsa.debian.org/games-team/angband in case you're interested in my hackish workarounds, but if we can get the fontconfig functionality into 4.2.6 I can dispense with all that!

[t4nk]

That would be better, though if name is the same as the contents of DEFAULT_FONT, it should either use quit()/quit_fmt() or print a diagnostic message about the default font not being available and return something that isn't PARSE_ERROR_NONE. Because when name is the same as the contents of DEFAULT_FONT and that font isn't loadable, either load_subwindow() will fail with an assertion failure or there'll be a later NULL pointer dereference for the subwindow's font field.

Mmm. That doesn't seem quite right to me. If subwindow->config is present, it won't even look at the DEFAULT_FONT:

static void load_subwindow(struct window *window, struct subwindow *subwindow)
{
    assert(window->loaded);
    assert(!subwindow->loaded);

    if (subwindow->font == NULL) {
        if (subwindow->config != NULL) {
            subwindow->font = make_font(window, 
                subwindow->config->font_name, subwindow->config->font_size);
        } else {
            subwindow->font = make_font(window, DEFAULT_FONT, 0);
        }
        assert(subwindow->font != NULL);
}

So I suppose the fix in config_subwindow_font() should be something like:

if (find_font_info(name) == NULL) {
    /* Looks like the old file was deleted, use the default one instead */
    subwindow->config->font_name = string_make(DEFAULT_FONT);
    subwindow->config->font_size = 0;
    return PARSE_ERROR_NONE;
}

Now, if DEFAULT_FONT is indeed not present, the ui won't work, which seems reasonable? Perhaps it could try the first font found in g_font_info[] in this case, or ask Fontconfig the equivalent of fc-match :spacing=mono. Or just die

Anyway, I'll need to reread all this stuff... and setup a Github account, because I don't remember the password for the old one... In the meantime, you might as well fix this one BTW, I think you did an excellent job maintaining this thing.

[backwardsEric]

This is mentioned in main-sdl2.c, line 6540:

if (find_font_info(name) == NULL) {
	/* TODO maybe its not really an error? the font file was
	 * probably just deleted and now the ui wont event start... */
	return PARSE_ERROR_INVALID_VALUE;
}

I propose to return PARSE_ERROR_NONE then. BackwardsEric, your opinion?

That would be better, though if name is the same as the contents of DEFAULT_FONT, it should either use quit()/quit_fmt() or print a diagnostic message about the default font not being available and return something that isn't PARSE_ERROR_NONE. Because when name is the same as the contents of DEFAULT_FONT and that font isn't loadable, either load_subwindow() will fail with an assertion failure or there'll be a later NULL pointer dereference for the subwindow's font field.

[t4nk]

I don't know how much crying there will be about the lack of choice - what would you do:

- release as is and wait for people to file bugs that their favourite font is missing
- link to a load more fonts so there are about the same number as there were before (they won't be identical but I can get a similar range of sizes without any more deps)
- add a note somewhere (like a README, News or changelog) telling people how to make symlinks to fonts they want to use in the game (in fact we could add this to the manual??)

After looking into it more, I propose to add functionality to SDL2 (and perhaps to SDL1) to use Fontconfig, if that is available (which it should be on Linux). That way Angband will be able to find all monospace fonts installed in a standard way (apt-get). ANGBAND_DIR_FONTS then can be used in addition to that, or as a fallback, if Fontconfig is not present.

The incantation to the command-line utility is something like fc-list :spacing=mono:scalable=true:style=regular -f '%{file}\n'

However, it probably makes more sense to use Fontconfig as a library. The documentation of it I found rather difficult to understand, but the source of fc-list provides an example: https://gitlab.freedesktop.org/fontc...ref_type=heads

[t4nk]

As an aside, fc-list :spacing=100 (in a shell) displays a list of monospace fonts installed on my machine (Debian Bookworm). This can perhaps be used for populating ANGBAND_DIR_FONTS?

edit: or even populating g_font_info[] directly? (#ifdef USE_FONTCONFIG, for example)

[t4nk]

Also, the first time someone tries to start the new version it will fail if their ~/.angband/Angband/sdl2init.txt refers to one of the old .fon files. If they start it from the command link they will get an error which will prompt them to delete the file, but if they start it from the .desktop icon they won't. This will need quite a big warning, as there's no way Debian can fix that for them.

This is mentioned in main-sdl2.c, line 6540:

if (find_font_info(name) == NULL) {
	/* TODO maybe its not really an error? the font file was
	 * probably just deleted and now the ui wont event start... */
	return PARSE_ERROR_INVALID_VALUE;
}

I propose to return PARSE_ERROR_NONE then. BackwardsEric, your opinion?

[Magnate]

So I went for the middle option and added all those fonts which replicate the originals. Of the missing ones, the only ones I've ever used are 8x8 and 10x14 but I'm happy to wait and see who complains.

[Magnate]

Out of interest, the fonts available in xfonts-base which are identical sizes to angband fonts are:

5x8
6x10
6x12
6x13
6x13b
7x13
7x13b
8x13
8x16
9x15
9x15b
10x20
12x24

This means that the ones not available are:

8x8
8x8b
8x12
8x12b
10x14
10x14b
12x18
16x16
16x24

[Magnate]

Thank you - I was happy not to patch the source, because I found both 8x13 and 10x20 fonts in xfonts-base, so we can use those and everything works. (The zero width problem is only extant for the SDL2 main window titles, none of the subwindows - including the one called the Angband window, which we would have called main - has the problem.)

[backwardsEric]

There is just one problem to solve: on starting the SDL2 front-end for the first time after installation, Angband seems hard-coded to expect one or two fonts - for me it was 8x13b for the title bar:

angband: main-sdl2.c:5129: load_status_bar: Assertion `window->status_bar.font != NULL' failed.

and 10x20 for the subwindows:

angband: main-sdl2.c:5587: load_subwindow: Assertion `subwindow->font != NULL' failed.

(Those errors went away when I replaced those font files.) Is there a way to control which fonts the SDL2 port looks for on starting up?

As you likely saw, those are hardwired in src/main-sdl2.c: look for DEFAULT_FONT and DEFAULT_STATUS_BAR_FONT. Probably easiest to patch the source to the source to substitute the names of the fonts you want to use instead. The DEFAULT_FONT has the complication that the size of that font is also specified (DEFAULT_FONT_W and DEFAULT_FONT_H) and used to set the initial size for subwindows (look for wipe_subwindow()).

The one issue I had was that it couldn't start up with a ttf font for the main window:

angband: font cache rendering failed for ' ' (ASCII 0) in font 'NotoMono-Regular.ttf': Text has zero width

One guess for what might be happening there is that main-sdl.c's g_ascii_codepoints_for_cache includes 0x01 to 0x1f because the packaged .fon files have graphics characters at those indices. You might revert the definition of g_ascii_codepoints_for_cache and the comment before it to what it was in
https://github.com/angband/angband/b...rc/main-sdl2.c :

/* the array of ascii chars was generated by this perl script:
 * my $ascii = join '', map /\p{Print}/ ? $_ : ' ', map chr, 0 .. 127; 
 * for (my $i = 0; $i < length($ascii); $i += 40) {
 *     my $s = substr $ascii, $i, 40;
 *     $s =~ s#\\#\\\\#g;
 *     $s =~ s#"#\\"#g;
 *     print qq(\t"$s"\n);
 * }
 */
static const char g_ascii_codepoints_for_cache[] =
	"                                 !\"#$%&'"
	"()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNO"
	"PQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvw"
	"xyz{|}~ ";

and see if that avoids the zero-width error.

[Magnate]

So in my fontfix branch (at salsa.debian.org/games-team/angband) I have a working build of 4.2.5+dfsg-2 which removes upstream fonts and patches the game to use two fonts from xfonts-base and one from fonts-noto-mono. I don't know how much crying there will be about the lack of choice - what would you do:

- release as is and wait for people to file bugs that their favourite font is missing
- link to a load more fonts so there are about the same number as there were before (they won't be identical but I can get a similar range of sizes without any more deps)
- add a note somewhere (like a README, News or changelog) telling people how to make symlinks to fonts they want to use in the game (in fact we could add this to the manual??)

Also, the first time someone tries to start the new version it will fail if their ~/.angband/Angband/sdl2init.txt refers to one of the old .fon files. If they start it from the command link they will get an error which will prompt them to delete the file, but if they start it from the .desktop icon they won't. This will need quite a big warning, as there's no way Debian can fix that for them.

[Magnate]

Progress! I can use symlinks to the 8x13 and 10x20 fonts in /usr/share/fonts/X11/misc and the SDL2 port starts up first time!

[Magnate]

So the good news is that this looks like it will work well. There seems to be no problem with symbolic links, either of the ttf fonts or the pcf.gz fonts renamed as .fon - both work fine once the game is running (including resizing the ttf fonts). There is just one problem to solve: on starting the SDL2 front-end for the first time after installation, Angband seems hard-coded to expect one or two fonts - for me it was 8x13b for the title bar:

angband: main-sdl2.c:5129: load_status_bar: Assertion `window->status_bar.font != NULL' failed.

and 10x20 for the subwindows:

angband: main-sdl2.c:5587: load_subwindow: Assertion `subwindow->font != NULL' failed.

(Those errors went away when I replaced those font files.) Is there a way to control which fonts the SDL2 port looks for on starting up? The one issue I had was that it couldn't start up with a ttf font for the main window:

angband: font cache rendering failed for ' ' (ASCII 0) in font 'NotoMono-Regular.ttf': Text has zero width

But it worked ok with a renamed pcf.gz font.

I will do some more purging and clean install testing, but any tips appreciated. The idea is to strip the .fon files out of the source tarball (like the sounds and other non-free stuff), and put in the symlinks on installation, and make the change to font-sdl2.prf so the centred dot shows up. Ideally the startup issues would be solved by symlinking known-working fonts, but I can also patch the source if something is hard-coded.

(Oh and I now know how to backport it to Debian 11 - watch this space!)

[backwardsEric]

Excellent, thank you, I'll look into those. Out of interest, why have you not included the fonts in /usr/share/fonts/X11 - are they inferior?

Most of the fonts (not sure about the ones in the Type1 directory) in /usr/share/fonts/X11 are bitmapped fonts (gzip compressed .pcf files) so, for setting up symbolic links in Angband's lib/fonts directory, the link would have to be renamed (since the SDL and SDL2 front ends expect bitmapped fonts to have a .fon extension; alternatively would have to make the scalable vs bitmapped font detection in those front ends more robust). Would have to verify that the renaming didn't interfere with SDL_ttf's ability to load the font. The fonts in the X11 directory appear to cover narrower ranges of glyphs (i.e. various flavors of ISO 8859), though that likely does not matter for the parts of Unicode currently used by Angband. Also, I don't know how fast the X11 to Wayland transition is going so I thought it best to avoid extra dependencies on X11 stuff.