Mason Font

By Geep, 2024

Introduction

Mason is a highly stylized font found in the large headlines at the top of the main menu pages. In English these read as:

• The Dark Mod (on main page)
• Missions List
• Online Mission Archive (with Online rendered smaller)
• Download Status
• Mission Details (and subheadings Description and Screenshots)
• Settings
• Load + Save

Headline characters are rendered in black, surrounded by a static golden-white "glow" (or a different effect if Russian). As a TDM font, provided in English (including Latin/European) and Russian, only the 48pt size is supplied, not 24pt or 12pt. That's because this font is not positioned for general use in FMs.

The information here will be of most interest to anyone seeking to extend or manipulate this font. Historical context hopefully sheds light on current complexities.

Origins

Back when the founders created TDM, the main menu headlines (including glow) were burnt into the parchment backgrounds of main pages. This was no doubt done with a font (likely Adobe's "Mason Alternate Serif") available within a graphics editor. And presumably with different page images for English and Russian, the two initial languages. [Please expand/refine this section if you were around then.]

2010-14 Era - A New Font to Support Translations

Drawing from Springheel's "Menu concerns for 1.08" and Tels' "Translating the TDM GUI" thread, particularly here.

When it came time to expand main menu headlines of that time to European languages (an effort Springheel and Tels led in 2010-14), the original method was replaced by a more flexible one: blank parchment backgrounds overlaid by a text font, plus the glow.

TTF Manipulation and Conversion

The starting point for that font [one assumes] was some Mason-like TTF font. It was likely Jonathan Barnbrook's 1992 "Mason Alternate", which has no separately styled lower case characters; lower-case is just a smaller version of upper-case.

Doom-era tools existed to programmatically convert a TTF file into a starting version of a TDM font, namely, a DAT file and a set of TGA (and ultimately DDS) images. (12pt and 24pt sizes were also generated, but only 48pt was pursued.) Furthermore, Tels reported working with graphics apps GIMP and Paintshop, that work directly with TTF fonts as well as TGA image files.

Bitmap Tweaking and Character Set Extension

The 48pt font was then further adapted to "TDM style" (internally, "MasonAlternate"), with some characters morphed to look more like their burned-in TDM predecessors. Substantial additional bitmap editing added Cyrillic and the full panoply of accented Latin characters. The result was a duplicated set of (initially) seven 256x256 bitmaps that would cover English, European, and Russian languages. While the bitmaps were "shared" (by duplication - unlike the case with other TDM fonts), the metadata DAT files for English+European and for Russian had different content (i.e., diverging in their included glyphs and codepoint mapping), and were generated by separate Font Patcher scripts. (Subsequently, the sharing became partial; see "Further Changes..." below.)

Enlarging Upper-Case Character of the New Font

Font Patcher scripting, as it generates a new, modified DAT file from an old one, can be asked to apply a scaling factor to specific characters. This does not affect the bitmap glyphs in any way, but instructs the TDM engine to scale at render-time. (See elsewhere for more about scaling within DAT files.)

Recall the starting Mason TTF font had lower case-letters that were the same as upper-case, except for size difference. But that difference seemed insufficient. After experimentation, it was decided to make the upper-case letter nominally 20% larger, by applying a scaling factor of 1.20 to them. (Actual scaling ratios recalculated from resulting DAT values will vary due to rounding-to-integer quantification.) This was applied to A-Z, as well as accented uppercase characters at codepoints 0x80-84, a2, a5, a6, a9-ac, b0, b2-b4, bc, be, and c0-dd.

Finalizing Russian

At this point, the /russian/ versions of the seven bitmap shaders were frozen, and remain unchanged to the current day (unless DarkFate independently has made further alterations; beyond our scope here). [There was a 2021 touch of all font file dates... was anything changed then?]

While a Russian "mason_glow" font was created and shipped, it is merely a placeholder: an exact duplicate of "mason", in regard to the content of their DAT files and their sets of DDS files. Instead, the Russian deployment provides a substitute visual effect by rendering each character twice.

Further Changes to English+European Mason During 2010-14

Bitmap Consolation

While /russian/ kept 7 bitmaps, as discussed, the /english/ set was compacted to 6, by combining characters from Masonalternate_5_48.dds and Masonalternate_6_48.dds into the former alone. The DAT file was appropriated adjusted.

Be aware that the compacted "english" set and the uncompacted "russian" set still encompass the same character glyphs; as before, their DAT files differ in what they expose.

Introducing Glow

TDM's Mason (as well as Carleton) supports a "glow" around each character. As deployed with the /english/ version of Mason, the glow is a static yellowish-white halo around each black character; it does not vary with mouse-over. Indeed, TDM's Mason headlines (as opposed to Carleton) are not mouse-selectable. The glow is not done with special engine coding, but rather by using the GUI system and separate bitmap sets for the base characters ("mason") and their glows ("mason_glow"). Each pair of base and glow characters will be aligned at render time, so must have compatible DAT metrics. (More about this below in a modern context.)

To accommodate the extra spacing needed for a glow, some glyphs were moved further away from a shader edge, where they had been placed by the programmatic conversion. Significant adjustments for glow spacing:

• Masonalternate_0_48.dds. No change.
• Masonalternate_1_48.dds. Top row english moved down.
• Masonalternate_2_48.dds. Top row english moved down.
• Masonalternate_3_48.dds. No change.
• Masonalternate_4_48.dds. Top row accented moved down. Left column accented moved right.
• Masonalternate_5_48.dds. (combines russian 5 & 6) Top row accented moved down.

The general GIMP method of creating a glow font bitmap from a copy of a base font bitmap is described here.

This results in paired base and glow bitmaps having the same character positioning, which while not required, is best practice and simplifies understanding when viewing in GIMP.

Be aware that though paired DDS files in /english/mason/ and /english/mason_glow/ have identical filenames, the content is different. For example, mason/masonalternative_0_48.dds and mason_glow/masonalternative_0_48.dds have respectively base content and glow content.

Resulting Bitmaps within GIMP, as Source

This discusses masonalternate_48.xcf, available...

• with filedate of May 26, 2012, unversioned in TDM SVN
• with filedate of March 28, 2014, within Tels' bloodgate archive of translated FMs. Font Patcher scripts (as .txt files) are found here too.

All 12 /english/ bitmaps are found as separate layers within a GIMP .xcf (project) file. The base character layers are called simply "0" to "5". The glow characters are called "New Layer", "New Layer #2", and so on. (Unfortunately, in this .xcf, they are unhelpfully misnumbered. Just know that a "New Layer" pairs with the base numbered layer immediately below it.) In addition, the early base seventh bitmap is represented here by the extra "Pasted Layer", whose characters (for /english/ not /russian/) were subsequently copied into layer 5.

So, as layers are individually exported as DDS files, they must be manually distributed appropriately:

• "New Layer" above "5" ==> mason_glow/fontimage_5_48.dds
• "5" ==> mason/fontimage_5_48.dds
• "New Layer" above "4" ==> mason_glow/fontimage_4_48.dds
• "4" ==> mason/fontimage_4_48.dds
• "New Layer" above "3" ==> mason_glow/fontimage_3_48.dds
• "3" ==> mason/fontimage_3_48.dds
• "New Layer" above "2" ==> mason_glow/fontimage_2_48.dds
• "2" ==> mason/fontimage_2_48.dds
• "New Layer" above "1" ==> mason_glow/fontimage_1_48.dds
• "1" ==> mason/fontimage_1_48.dds
• "New Layer" above "0" ==> mason_glow/fontimage_0_48.dds
• "0" ==> mason/fontimage_0_48.dds

Deployment and European String Support

Regarding Mason, it was the plan to provide translated text and GUI methodology to all the main menu headlings, e.g., "Settings", "Load/Save", and "Mission Archive". [There are indications this was only realized for some headlines, and finally completed during the 2017-18 update.]

2017-18 Era - Improving English Appearance

Adapted from Springheel's thread "Menu Update".

As time went on, it was observed that the 48pt-sized characters used in Mason, while of adequate crispness for the screen resolutions of Doom and early TDM, were showing their age. In 2017-8, Springheel undertook a revision to fix this. This effort focused on just the English alphabetic characters In the /english/ set. The method involved:

• Doubling the size of selected bitmap shaders from 256 x 256 to 512 x 512. This involved enlarging the bitmap image, so doubling the size of every glyph contained within (since the goal here was not to pack in more glyphs per bitmap.) Fortunately, the size the characters appearance in-game is unchanged, if the DAT file metrics are unaltered.
• Within the doubled shaders, selecting and modifying individual glyphs to make them render more crisply.

Selective Doubling of "Mason"

An analysis showed that only Mason's first three shader bitmaps contained the characters of interest. So expeditiously, only those were doubled to 512x512. This doubled the size of glyphs of all characters within, including those not of improvement interest. (By not doubling all six bitmaps, the resulting mixed-bitmap dimensions in the set has drawbacks for GIMP layering and tool usage, discussed later.)

In spite of this doubling, the characters must not change in size when rendered. This is done by keeping the DAT's metrics – particularly imageHeight and imageWidth - unchanged, as well as floating-point boundaries s, t, s2, and t2 expressed as 0..1, but now within the doubled 512 x 512 size.

Expressed in REF terms, the values of imageHeight and imageWidth are unchanged from their 256 x 256 values, but coord_s, coord_t, coord_s2, and coord_t2 integers are doubled. So, as integer coordinates, this may be viewed as applying a 0.50 scaling factor – or for upper-case ASCII characters, composing 0.50 and 1.20 scaling factors.

Selective Doubling of "Mason_glow"

Surprisingly, of the corresponding 3 glow bitmaps, only 2 of them were doubled. There are pluses and minuses to doubling glow bitmaps. The main argument "for" is that it permits easy visualization as layers in apps like GIMP. The main argument "against" is that, since the glows are supposed to be fuzzy, they don't really need to be sharpened.

In any event, the base and glow don't require the same size shader for proper alignment. The specific requirement is that the following must match for each base and glow character in their respective DAT files:

• horizontal border dimension s2-s, expressed as a floating point value 0...1
• vertical border dimension t2-t, expressed as a floating point value 0...1
• All other numeric metadata.

If border dimensions are expressed as pixel integer in REF terms, this is more complicated, as each border must reflect an appropriate range of 0...256 or 0...512, depending on its bitmap shader.

Black Borders Appear

In general, TDM fonts represent every glyph as pure white (RGB 1,1,1), delineated only by alpha channel edges. This was true for mason within the previous-era's /english/ and /russian/ DDS files.

But in the 3 /english/ base mason dds files that were doubled, every character somehow got a ragged black border (when viewed in GIMP). Specifically, these "black border" glyphs are gray-scale (or maybe black/white dithered) with smudgy white interiors. Perhaps that doesn't matter so much when game-rendered in black, but still, unhelpful.

Selective Sharpening/Redrawing

Finally, the bitmap glyphs were editing to make crisper edges. This was limited to "regular keyboard characters", not "alternative language characters" (e.g., accented or Cyrillic). For these characters, the "black borders" problems was overwritten: the black borders were minimized (though not eliminated), and the interiors were cleaned to be pure white. [Done with flood fill?]. But the problem remains for other characters.

Coverage

Coverage was completed so that all headlines (e.g., Settings, Load/Save, Mission Archive) were rendered translated into European languages. But only the unaccented English characters were uniformly improved.

Resulting Bitmaps as Files

To summarize the /english/ base results...

Now of size 512x512 (342 KB), and containing (though not exclusively) redrawn English characters:

• Masonalternate_0_48.dds
• Masonalternate_1_48.dds
• Masonalternate_2_48.dds

Of size 256 x 256 (86 KB), and not containing English characters, so no redrawing:

• Masonalternate_3_48.dds
• Masonalternate_4_48.dds
• Masonalternate_5_48.dds

Mason Today

Bitmaps as Files

The final file formats discussed above are still the formats in use today, of TDM 2.12 "mason" and "mason_glow" bitmaps with Jan. 17, 2021 filedates found under "tdm_fonts01/dds/fonts/english/" and "/russian/.

Drawbacks of Mixed-Size Bitmaps

With GIMP

While you can view multiple images in GIMP, if they are of different sizes, a view of them in aligned layers becomes impractical. This weighs against the use of a single .xcf file to serve as overall source for the set. Instead, individual TGA images make more sense. These can still be edited one at a time in GIMP.

With Refont and datBounds

Refont v2.5 now supports mixed-sized bitmaps. See in particular Refont#Mason Family.

Though an improvement is planned, datBounds does not currently support mixed-size bitmaps.

How Mason's "Glow" is Implemented

A typical usage is the mainmenu_download.gui, where two representations of the current string are overlaid in an aligned manner. One is the text, rendered as opaque black (using RGBA 0,0,0,1). The other is the glow, rendered in pale yellow with some transparency (RGBA 1,1,0.80,0.8). The glow source already has some transparency, so this is even more. For a given character, the glow bitmap has wider and more diffuse strokes than the base font. A link about glow bitmap creation is above.

Here's one representative gui code snippet, showing placement of the words "Mission Archive" (or it's non-English equivalent), on a parchment background:

...
   // Mission Archive Headline Translation
   windowDef MissionArchiveHeadlineTextGlow
   {
     rect 10, 15 + "gui::headline_offset", 300, 100
     text "#str_menu_mission_archive" // Mission Archive
     font		"fonts/mason_glow"
     forecolor 1,1,0.80,0.8
     textscale	0.65
     textalign 1
     textaligny -1
     visible 1
   }
   windowDef MissionArchiveHeadlineText
   {
     rect 10, 15 + "gui::headline_offset", 300, 100
     text "#str_menu_mission_archive" // Mission Archive
     font		"fonts/mason"
     forecolor 0,0,0,1.0
     textscale	0.65
     textalign 1
     visible 1
   }
...

Observe that the similarity of rect, textscale, and textalign values keeps the two overlays exactly aligned, except for a 1 pixel vertical offset given by textaligny -1.

(Additional GUI event handling, not shown, allows the paired textscale values to be reduced to accommodate a more-verbose European language.)