Fonts: Colors and dimensions

[OnlineCop]

We should have a class/struct for fonts and either blend or remove one/both of the eFont/eFontColor enums. If we have a std::map or std::vector of fonts, the enum values could still be used to indicate which font we're after.

enum eFont
{
    FONT_WHITE = 0,
    FONT_RED = 1,
    FONT_YELLOW = 2,
    FONT_GREEN = 3,
    FONT_PURPLE = 4,
    FONT_DECIDE = 5,

    NUM_FONTS // always last
};
enum eFontColor
{
    FNORMAL = 0,
    FRED = 1,
    FYELLOW = 2,
    FGREEN = 3,
    FDARK = 4,
    FGOLD = 5,
    FBIG = 6,

    NUM_FONT_COLORS // always last
};

The struct should include the font dimensions (height, width) since these are monospaced fonts, and possibly color (or at least an index value within pal[] if we're wanting to recolor them).

KDraw::print_font() typically multiplies the font width by some offset, and I'd like to replace those Magic Number multiplications (* 8 ) with * font.width() or something similar.

This should also make it easier to extend the fonts in the future, in support of localization in case the current fonts.png doesn't contain all the necessary characters.

[OnlineCop]

When looking over the font system, sfonts appears to be only digits 0..9 while kfonts appears to be ASCII [0x20..0x79] plus a handful of codepoints.

sfonts[5]

• Loaded from misc.png.
• Uses the eFont enum to determine which to draw.
• Each contains a single row of 8x8 glyphs:
  • sfonts[0] is white text with a blue shadow
  • sfonts[1..4] are recolored to be red/yellow/green/grey text with the same blue shadow.
• Contains glyphs in range 0..9 (only digits).

kfonts

• Loaded from fonts.png.
• Uses the eFontColor enum to determine which to draw.
• kfonts[0..4] are solid-color (white, red, yellow, green, grey) 8x8 glyphs with a black shadow.
• kfonts[5] are multi-colored gold 8x8 glyphs with a blue shadow.
• kfonts[6] are solid-color white 8x12 glyphs with a black shadow.
• Contains glyphs in range [0x20..0x7F] plus a few select Unicode characters.
  • Note that kfonts[0..4] have modified some of the characters:
    • < became a "left arrow" glyph
    • > became a "right arrow" glyph
    • @ became a "down arrow" or "down chevron" glyph
    • ^ became an "x" (like the math symbol for multiply) glyph
  • Both kfonts[5] (gold) and kfonts[6] (tall white) appear to keep the original font values.

[OnlineCop]

As far as the structure of the struct goes, we'd need to track which glyphs it contains, and most likely a copy of a Raster* object so we can remove the dependency of the sfonts/kfonts globals.

Functions like KDraw::print_font() (prints all glyphs from kfonts) and KDraw::print_num() (prints digits only from sfonts) may need to be able to handle when an index is outside the range of the font's glyphs. In those cases, I don't think they should abort the game. They should remove the invalid character (shortening the word) or substitute another glyph in its place to indicate that it can't be rendered.

That would mean that, assuming 'X' here is an unknown or out-of-range value, "abXcXd" could be rendered as:

• "abcd" (invalid characters removed)
• "ab c d" (invalid characters become a blank)
• "abOcOd" (invalid characters replaced by some glyph to indicate it can't be rendered)

[pedro-w]

On the other hand, all the text shown in the game comes from within the game, so if we've put in some un-displayable code points I'd rather we knew as soon as possible rather than risk them going undetected.

[OnlineCop]

It might become necessary to switch to using real fonts, so the gettext()-translated strings can actually render properly in all of the target languages.

When someone localizes our _(...) wrapped text with PO files, I fear that the characters not explicitly added to the glyphs lookup will cause issues.