FAangband 0.3.4

[Nick]

Looking through the fonts using Softy (font editor recommended by L.M.).

Yes, I got this far.

Only differences I found vs. 0.2.3 is that the new fonts have 96x96 dpi . So I set the 8X13X fon to 96dpi and everything seems fine !

But I didn't think of this! Well done - I have given it a quick test in XP and it seems fine, and I suspect also Vista (although I haven't checked thoroughly yet). In any case, I'll do some thorough checking now.

[Arralen]

Problem solved .. I hope - needs testing !

Looking through the fonts using Softy (font editor recommended by L.M.).

Only differences I found vs. 0.2.3 is that the new fonts have 96x96 dpi . So I set the 8X13X fon to 96dpi and everything seems fine !

[zaimoni]

OK - I think I'm getting closer to understanding. Next question - is the problem that the font scaling is being done wrong, or that, having determined the font size, the operating system then uses a font of that size that it already knows about instead of the angband font?

FAA font reading code for Windows port is identical to V's.

If the font scale estimated from the filename does not match the actual font scale, the font can be scaled wrong in the Windows port. The SDL port is immune, as it doesn't have this estimation code. The purpose of caching the font scale in the filename for Windows is to avoid using a resource that is strictly limited.

(Checking Windows API):
Don't see anything blindingly obvious, but the next release of Zaiband is going to use FF_MODERN rather than FF_DONTCARE in the Windows port's CreateFont call to force the fallback to be constant-width.

[Nick]

In V, the current algorithm is to read the font metrics from the filename if possible, hand the file-named metrics to CreateFont, and then interrogate Windows if the font metrics were not completely read from the filename.

OK - I think I'm getting closer to understanding. Next question - is the problem that the font scaling is being done wrong, or that, having determined the font size, the operating system then uses a font of that size that it already knows about instead of the angband font? Or is it neither of those?

[Atriel]

I'm not sure that provides sufficiently more than the show options in lists that you already have...?

Oops, sorry, i´ve just noticed that there is already a show_list option... ignore my previous post about that

[zaimoni]

The problem is in the font sizing, then. I don't have time to look at it this instant, but I'd be checking differences between V analyze_metrics and FAA analyze_metrics in main-win.c.

In V, the current algorithm is to read the font metrics from the filename if possible, hand the file-named metrics to CreateFont, and then interrogate Windows if the font metrics were not completely read from the filename.

[Nick]

Yes, this is exactly the behaviour that has me confused. To add to the confusion, 8x13x.fon works fine in the linux SDL port. This makes no sense to me - it appears as if windows is actually using a different font.

[Arralen]

The 8x12 fon, however, works correctly ?!

[Arralen]

Some more fon trouble ..

The 8x13 fon works much better for me.
Sadly, if I turn on the "full" rock squares by using the "font-win.prf" file, I get this (not matter which graphics settings I use):

[Nick]

It sounds like the visuals editor is out-of-sync on which font it should be using.

I should have been clearer - it's not just the visuals editor, it's any use of the font in FA (like the map display).

Does this affect V as well? If so (and I have enough of a how-to-trigger), I'll take a look at fixing it for V and Zaiband. [Ahem...I don't like what I'm seeing in the C source -- is there any reason I shouldn't clean this up anyway?]

It probably doesn't affect V - I think this may be an FA-specific problem, as NPP seems to be fine. The only thing I can see different in main-win.c between the two is that NPP does a cast to (unsigned char) in a few places where FA doesn't - but I'm probably missing something. And cleaning up seems like a good idea.

[zaimoni]

On font questions, does anyone know how on earth windows chooses it's font? The windows port will display accented characters if you choose a font containing them, but looking at the visuals editor from the knowledge screen it doesn't show the angband font but a system one. And yet if you choose a font size where the angband font values only go to 127, the same will be true of the font that is used. This seems bizarre to me.

(Arches eyestripes)

It sounds like the visuals editor is out-of-sync on which font it should be using.

Currently (V):
RemoveFontResource and AddFontResource controls whether the font is even available. CreateFont actually makes the font usable; DeleteObject deallocates when the font is no longer used.

Does this affect V as well? If so (and I have enough of a how-to-trigger), I'll take a look at fixing it for V and Zaiband. [Ahem...I don't like what I'm seeing in the C source -- is there any reason I shouldn't clean this up anyway?]

[Nick]

I always thought that pseudo-graphical characters should really be made into a graphics option. Putting them in a font seems like a hack.

Well, yes, but what's the harm? The advantage is that they can be handled through pref files, and you don't need a different one for each colour. My chief reason for not using graphics when I play is that, for a given grid size, the alphabet is easier to identify at a glance than any tileset - after all, it has been developed for exactly that. But for handling terrain, which only has a relatively small number of distinct types needed, I am starting to rather like the little fonty things.

On font questions, does anyone know how on earth windows chooses it's font? The windows port will display accented characters if you choose a font containing them, but looking at the visuals editor from the knowledge screen it doesn't show the angband font but a system one. And yet if you choose a font size where the angband font values only go to 127, the same will be true of the font that is used. This seems bizarre to me.

[zaimoni]

I always thought that pseudo-graphical characters should really be made into a graphics option. Putting them in a font seems like a hack.

Having worked through the TrueType specification (before concluding that it was infeasible to write a font editor de novo quickly): the only hack is overloading code points.

The TrueType font format specifications assume a virtual screen with a very high resolution (at least 2800 dpi), and have some medium-level drawing primitives.

[Seany C]

So if you take the zip file, unzip it into your lib/xtra/font folder, and then select "8x13x.fon" as your term-0 font, it should look just like 8x13 except that the extended characters will display properly.

Woohoo - sounds perfect - ta. I'll check it in XP over the weekend...

[takkaria]

I always thought that pseudo-graphical characters should really be made into a graphics option. Putting them in a font seems like a hack.