The DarkMod Wiki - User contributions [en]

I18N - Charset

2026-06-11T19:59:49Z

Geep: /* Font Encoding for European Languages */ Note at top about 0x80-0x9f range

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== LANG File Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of either the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

or, more recently, the Windows C++ utility program '''gen_lang_plus'''. [[Gen_Lang_Programs]] has details of these.

This process ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Language-specific files (f.i. '''german.lang''') provide string dictionaries. A system-wide set is provided in tdm_base01.pk4/strings/. A deployed FM may offer similar files in its /strings/ folder... at the very least '''english.lang'''. All such files are expected to be in the following 8-bit encodings:

* '''Czech, Hungarian, Slovak, Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''Turkish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-9 ISO-8859-9]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1]. This covers TDM-supported languages English, German, Italian, Spanish, Portuguese, Swedish, Danish, Dutch, and Catalan.

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character Remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the two special ones (respectively for Latin and Cyrillic) that TDM uses and that are described next. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found in "tdm_base01.pk4/strings" (and there is no "default.map" there, which is the case these days), then no remapping takes place. Generally, ISO-8859-1 languages do not require remapping. The map files for the four ISO-8859-2 languages have identical content.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

== Font Encoding for European Languages ==

This TDM-specific 8-bit encoding applies to all TDM fonts for English/European languages, that is, everything except the Cyrillic-based Russian. This encoding controls the ordering within a font's binary DAT file.

Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character. In addition, printable characters in the range 0x80-0x9f, shown in light or dark green, are also TDM characters, replacing ISO-8859 control characters (not shown).

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

== Font Encoding for Russian Cyrillic ==

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6. (This was to overcome a historical Doom3 bug that is now fixed. But to date "the remapping for Russian is still in place, tho, to avoid having to patch all the russian fonts", says bug report [https://bugs.thedarkmod.com/view.php?id=2812 "0002812: Character 0xFF does not work in fonts"]).

=== Cyrillic Character Implementation ===
Within any given font, character coverage may be incomplete.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints, and included in TDM 2.14.

== Future Extensions to Unicode and/or Asian Languages (Korean, Chinese, Japanese)? ==

It is possible to visualize a transition to a DAT format (and engine code) that supported UCS (16-bit) Unicode, allowing the existing fonts to then be expanded to cover more characters. Then perhaps all.lang would be the only .lang needed.

As for Asian languages, the original D3 had support for them, so it might be possible to add them to TDM, too, but with a heavy burden on font development and translation. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

[[Category:Fonts]]

{{i18n}}

I18N - Charset

2026-05-31T21:35:16Z

Geep: /* Character Remapping */ mention ISO-8859-2

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== LANG File Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of either the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

or, more recently, the Windows C++ utility program '''gen_lang_plus'''. [[Gen_Lang_Programs]] has details of these.

This process ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Language-specific files (f.i. '''german.lang''') provide string dictionaries. A system-wide set is provided in tdm_base01.pk4/strings/. A deployed FM may offer similar files in its /strings/ folder... at the very least '''english.lang'''. All such files are expected to be in the following 8-bit encodings:

* '''Czech, Hungarian, Slovak, Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''Turkish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-9 ISO-8859-9]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1]. This covers TDM-supported languages English, German, Italian, Spanish, Portuguese, Swedish, Danish, Dutch, and Catalan.

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character Remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the two special ones (respectively for Latin and Cyrillic) that TDM uses and that are described next. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found in "tdm_base01.pk4/strings" (and there is no "default.map" there, which is the case these days), then no remapping takes place. Generally, ISO-8859-1 languages do not require remapping. The map files for the four ISO-8859-2 languages have identical content.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

== Font Encoding for European Languages ==

This TDM-specific 8-bit encoding applies to all TDM fonts for English/European languages, that is, everything except the Cyrillic-based Russian. This encoding controls the ordering within a font's binary DAT file.

Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

== Font Encoding for Russian Cyrillic ==

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6. (This was to overcome a historical Doom3 bug that is now fixed. But to date "the remapping for Russian is still in place, tho, to avoid having to patch all the russian fonts", says bug report [https://bugs.thedarkmod.com/view.php?id=2812 "0002812: Character 0xFF does not work in fonts"]).

=== Cyrillic Character Implementation ===
Within any given font, character coverage may be incomplete.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints, and included in TDM 2.14.

== Future Extensions to Unicode and/or Asian Languages (Korean, Chinese, Japanese)? ==

It is possible to visualize a transition to a DAT format (and engine code) that supported UCS (16-bit) Unicode, allowing the existing fonts to then be expanded to cover more characters. Then perhaps all.lang would be the only .lang needed.

As for Asian languages, the original D3 had support for them, so it might be possible to add them to TDM, too, but with a heavy burden on font development and translation. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

[[Category:Fonts]]

{{i18n}}

I18N - Charset

2026-05-31T20:54:10Z

Geep: Rearrange sections

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== LANG File Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of either the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

or, more recently, the Windows C++ utility program '''gen_lang_plus'''. [[Gen_Lang_Programs]] has details of these.

This process ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Language-specific files (f.i. '''german.lang''') provide string dictionaries. A system-wide set is provided in tdm_base01.pk4/strings/. A deployed FM may offer similar files in its /strings/ folder... at the very least '''english.lang'''. All such files are expected to be in the following 8-bit encodings:

* '''Czech, Hungarian, Slovak, Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''Turkish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-9 ISO-8859-9]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1]. This covers TDM-supported languages English, German, Italian, Spanish, Portuguese, Swedish, Danish, Dutch, and Catalan.

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character Remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the two special ones (respectively for Latin and Cyrillic) that TDM uses and that are described next. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found in "tdm_base01.pk4/strings" (and there is no "default.map" there, which is the case these days), then no remapping takes place. Generally, ISO-8859-1 languages do not require remapping.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

== Font Encoding for European Languages ==

This TDM-specific 8-bit encoding applies to all TDM fonts for English/European languages, that is, everything except the Cyrillic-based Russian. This encoding controls the ordering within a font's binary DAT file.

Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

== Font Encoding for Russian Cyrillic ==

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6. (This was to overcome a historical Doom3 bug that is now fixed. But to date "the remapping for Russian is still in place, tho, to avoid having to patch all the russian fonts", says bug report [https://bugs.thedarkmod.com/view.php?id=2812 "0002812: Character 0xFF does not work in fonts"]).

=== Cyrillic Character Implementation ===
Within any given font, character coverage may be incomplete.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints, and included in TDM 2.14.

== Future Extensions to Unicode and/or Asian Languages (Korean, Chinese, Japanese)? ==

It is possible to visualize a transition to a DAT format (and engine code) that supported UCS (16-bit) Unicode, allowing the existing fonts to then be expanded to cover more characters. Then perhaps all.lang would be the only .lang needed.

As for Asian languages, the original D3 had support for them, so it might be possible to add them to TDM, too, but with a heavy burden on font development and translation. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

[[Category:Fonts]]

{{i18n}}

I18N - Charset

2026-05-31T20:29:59Z

Geep: /* Character remapping */ Rewrite intro & future extensions, change heading nesting

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of either the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

or, more recently, the Windows C++ utility program '''gen_lang_plus'''. [[Gen_Lang_Programs]] has details of these.

This process ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Language-specific files (f.i. '''german.lang''') provide string dictionaries. A system-wide set is provided in tdm_base01.pk4/strings/. A deployed FM may offer similar files in its /strings/ folder... at the very least '''english.lang'''. All such files are expected to be in the following 8-bit encodings:

* '''Czech, Hungarian, Slovak, Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''Turkish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-9 ISO-8859-9]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1]. This covers TDM-supported languages English, German, Italian, Spanish, Portuguese, Swedish, Danish, Dutch, and Catalan.

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character Remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the two special ones (respectively for Latin and Cyrillic) that TDM uses and that are described next. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found in "tdm_base01.pk4/strings" (and there is no "default.map" there, which is the case these days), then no remapping takes place. Generally, ISO-8859-1 languages do not require remapping.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

== Encoding for European Languages ==

This TDM-specific 8-bit encoding applies to all TDM fonts for English/European languages, that is, everything except the Cyrillic-based Russian.

Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

== Encoding for Russian Cyrillic ==

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6. (This was to overcome a historical Doom3 bug that is now fixed. But to date "the remapping for Russian is still in place, tho, to avoid having to patch all the russian fonts", says bug report [https://bugs.thedarkmod.com/view.php?id=2812 "0002812: Character 0xFF does not work in fonts"]).

Within any given font, character coverage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

== Future Extensions to Unicode and/or Asian Languages (Korean, Chinese, Japanese)? ==

It is possible to visualize a transition to a DAT format (and engine code) that supported UCS (16-bit) Unicode, allowing the existing fonts to then be expanded to cover more characters. Then perhaps all.lang would be the only .lang needed.

As for Asian languages, the original D3 had support for them, so it might be possible to add them to TDM, too, but with a heavy burden on font development and translation. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints, and included in TDM 2.14.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

I18N - Charset

2026-05-31T19:42:25Z

Geep: /* All other language files */ Update/correct language list

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of either the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

or, more recently, the Windows C++ utility program '''gen_lang_plus'''. [[Gen_Lang_Programs]] has details of these.

This process ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Language-specific files (f.i. '''german.lang''') provide string dictionaries. A system-wide set is provided in tdm_base01.pk4/strings/. A deployed FM may offer similar files in its /strings/ folder... at the very least '''english.lang'''. All such files are expected to be in the following 8-bit encodings:

* '''Czech, Hungarian, Slovak, Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''Turkish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-9 ISO-8859-9]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1]. This covers TDM-supported languages English, German, Italian, Spanish, Portuguese, Swedish, Danish, Dutch, and Catalan.

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6. (This was to overcome a historical Doom3 bug that is now fixed. But to date "the remapping for Russian is still in place, tho, to avoid having to patch all the russian fonts", says bug report [https://bugs.thedarkmod.com/view.php?id=2812 "0002812: Character 0xFF does not work in fonts"]).

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints, and included in TDM 2.14.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

I18N - Character mapping

2026-05-31T18:08:57Z

Geep: /* Encodings */ Update/correct language encodings, default file info

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, a special font is used (Carleton for the menu f.i.). These fonts are build/patched so that the right characters appear in the right place.

== Encodings ==

Whether used to define translation dictionaries that are system-wide (in tdm_base01.pk4/strings/) or FM-specific (in <FM>/strings/), language files (f.i. german.lang), derived from Unicode all.lang, are expected to be in the following encodings:

* '''Czech, Polish, Hungarian, Slovak:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''Romanian:''' ISO-8859-16
* '''French:''' ISO-8859-15
* '''Turkish:''' ISO-8859-9
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1]. This covers English, German, Italian, Spanish, Portuguese, Swedish, Danish, Dutch, and Catalan.

=== Remapping ===

The characters are remapped upon loading the dictionary/readable from their source encoding (e.g. ISO 8859-2) to the special character map TDM uses. Responsible for this are mapping files, f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead. (Note: a default map is no longer shipped, at least since TDM 2.10 and probably much earlier. Generally, ISO-8859-1 languages don't need remapping.)

Remapping files are only looked for in the tdm_base01.pk4/strings directory. So they cannot be overwritten in any .map file placed in an FM's string directory.

The content of a map file is wrapped in '''{''' and '''}''', and each mapping consists of two hexadecimal numbers, the source and the target character number.

== Examples ==

For russian:

<pre>
{
0xFF 0xB6 // я
}
</pre>

For European languages in ISO 8859-2 charset (f.i. Czech):

<pre>
// a comment
{
0xF2 0xA1 // ň
0xDB 0xA2 // Ű (similiar to Ü, used in Hungarian)
0xFB 0xA4 // ű
0xA9 0xA6 // Š
0xB9 0xA8 // š
0xA1 0xAA // Ą
0xC8 0xAC // Č
0xCA 0xAB // Ę
0xE8 0xAE // č
0xD5 0xB0 // Ő (similiar to Ö, used in Hungarian)
0xA3 0xB1 // Ł
0xAb 0xB2 // Ť
0xCF 0xB3 // Ď
0xAC 0xB4 // Ž
0xB3 0xB5 // ł
0xBf 0xB6 // ż
0xEF 0xB7 // ď
0xBE 0xB8 // ž
0xF5 0xB9 // ő (similiar to ö, used in Hungarian)
0xB1 0xBA // ą
0xEA 0xBB // ę
0xF8 0xF7 // ř
0xD8 0xD7 // Ř
0xEC 0xA3 // ě
0xCC 0xA5 // Ě
0xD9 0xA9 // Ů
0xF9 0xAF // ů
0xBB 0xB6 // ť
}
</pre>
{{i18n}}* [[Font Patcher]]

[[Category:fonts]]

I18N - Charset

2026-05-31T16:42:46Z

Geep: /* Russian */ explain remapping, link to bug report

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of either the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

or, more recently, the Windows C++ utility program '''gen_lang_plus'''. [[Gen_Lang_Programs]] has details of these.

This process ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6. (This was to overcome a historical Doom3 bug that is now fixed. But to date "the remapping for Russian is still in place, tho, to avoid having to patch all the russian fonts", says bug report [https://bugs.thedarkmod.com/view.php?id=2812 "0002812: Character 0xFF does not work in fonts"]).

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints, and included in TDM 2.14.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

Gen Lang Programs

2026-05-31T03:00:50Z

Geep: /* Introduction to Gen_lang.pl ("PL") and Gen_lang_plus ("PLUS") */

By Geep, from February 2025
== Introduction to Gen_lang.pl ("PL") and Gen_lang_plus ("PLUS") ==
This describes two software implementations of command-line programs that essentially do the same thing;
# The Perl program "gen_lang.pl" (dubbed here PL), created by Tels in the 2010-14 timeframe. This is easily deployed under Linux that has Perl capabilities. Version 17 Is current.
# The C++ program "gen_lang_plus" (dubbed here PLUS), a re-implementation with minor improvements created by Geep in 2025. This is lightly Windows-specific at this time. (Please volunteer if you want to make it run under Linux.) For the current version, see "Downloads" at this article's end.

The purpose of both is as follows.
* Read and write files in child folder "strings". (Caution: "not strings/fm", even if you specify the "fm" option.)
* Read an "all.lang" file, either that associated with the main-menu-system, or with a specific FM under development. This UTF-8 input file has translations of strings for all TDM-supported languages (currently 17). There are individual sections for each target language. Each string is of form

"#str_<id>" "<string content>" // optional comment.
* Generate a set of individual "<language>.lang" files, with the appropriate translated strings. Each file is generated in a standard 8-bit encoding (e.g., defined by one of the iso-8859 standards) designated for the target language. If a translator did not provide a given string in the target language, the master English string is automatically substituted.
* Finally, as requested by command-line options, various analyses can be performed. For example, a set of "missing_<language>.txt" files can be generated, to suggest where translation efforts are still needed.
This article details both programs, with important differences noted. Running this functionality is intended to be done, infrequently, by the person overseeing translation improvements to all.lang.

For more quick overviews of this process, see
* the wiki article [[Internationalization]]. This also covers the i18n.pl program, which is beyond the scope here.
* the preamble of the all.lang file, found in tdm_base01.pk4's \strings\.

It is helpful to mention what these two programs do '''not''' take into account:
* the <language>.map file that reroutes European codepoints from a standardized encoding to the TDM-specific custom 8-bit encoding discussed in [[I18N_-_Charset]].
* what UTF8 characters are allowed by that TDM-specific coding (as opposed to the ISO-8859 encoding).
* the font and fontsize a specific string will use, and what limitations that entails, and what within-DAT glyph-substitutions may be in effect.

== Runtime Environment for PLUS ==
To function in all aspects, PLUS requires Windows with certain UTF8 capabilities, introduced in later versions of Windows 10. Because the PLUS build is told explicitly to use UTF8, in theory what your "system locale" is set to should not matter. In particular, you are not required you set the system locale to the Windows 11 beta UTF8 codepage. (PLUS was developed on a dev box with the English (US) locale.)

You may run it under the traditional Windows console. However, that will not display UTF8 characters correctly on screen, which is mainly an issue with the -charstats and -charpunts options. Instead, use Windows Terminal (or Powershell with UTF8 encoding). Or pipe the console output to a file (i.e., "> myfile.txt"), that can be viewed as UTF8 with Notepad and other text editors.

== Overview of Command-Line Options ==

===For both PL and PLUS===
--csv Generate CSV file
--missing Generate files with lists of missing strings for each language.
--charstats Generate statistics about foreign characters.
--show-ranges Show occupied string index ranges.
--show-holes Show holes in the string index ranges.

With PLUS, one may use a single "-" before an option, instead of "--", and/or leave off the "show-" prefix. (Regarding "charstats", for consistency, since this option outputs to screen, PL should have used the "show-" prefix, but didn't. PLUS does, optionally.)

===For PLUS Only===
-old-preamble Keep <language>.lang preamble just like that of gen_lang.pl. Don't include file generation date or PLUS version number.
-charpunts ''or'' --show-charpunts Reports lines in which "?" was substituted for any character.
-charpunts-extra ''or'' --show-charpunts-extra Like charpunt, but includes "// comment" characters.
-fm Program used for an fm, not main menu; affects what's considered a valid numeric #str_<id> range.
-cvs-unsorted Like -csv, but row order stays like that of all.lang [English].

== Charpunts and Charpunts-Extra Options [PLUS Only] ==
During generation of a particular <language>.lang file, if a valid data line contains 1 or more characters that can't be rendered in the target encoding, then a 3-line report is issued to console. Specifically:
-charpunts Considers characters within the line's content (excluding comments).
-charpunts-extra Same as charpunts, but also considers characters within the line's "// comment".

When entering these options, you may use the "show-" prefix if you'd like, with 1 or 2 leading dashes.

By "// comment", is meant the optional comment that starts with "//" at the end of a #str_<id> line (but still excluding any other comment forms; these latter won't be present in <language>.lang).

Note – it is assumed that #str_<id> contains only 0-9, A-Z, a-z, or underline... so is not inspected by these options.

An example report for [Hungarian] encoded as iso-8859-2:

Output line 177...
from: "#str_02208" "Küldetési idõ"
to: "#str_02208" "K�ldet�si id?"

Important: in this example, only õ, the last character in the "from:" line, could not be encoded in iso-8859-2 and so is replaced by "?" in the "to:" line. The "to:" line characters indicated by � were successfully encoded, but now are not valid UTF8, so can no longer be shown as such. That is, the "to:" line has the identical string placed into the hungarian.lang file.

Here is an -charpunts-extra example where only the comment has characters that don't encode, in this case into iso-8859-1 for [English]:

Output line 396...
from: "#str_02482" "Srpski"// Serbian (Српски - same exception as Russian)
to: "#str_02482" "Srpski"// Serbian (?????? - same exception as Russian)

TIP: If the results of this option is too voluminous, recall that output from a console app can be directed into a file using "... > filename.txt".

These reports give the output line number within <language>.lang, rather than the input line in all.lang, because of difficulties getting the latter value to be correct in the face of, for instance, multiline comments. (Any line numbers that PL reports are usually off.)

== Old Preamble Option [PLUS Only] ==
Each <language>.lang file gets a standard preamble. For PL, the first line looks like this example:
// String table - english (iso-8859-1)

For PLUS, the first line by default also has UTC time and program version, like this example:
// String table - english (iso-8859-1) - created on 2025-02-15T04:00:21Z with gen_lang_plus v. 1.0

But you can ask PLUS to use PL's format, with the "-old-preamble" option. Why? To simplify comparing a particular <language>.lang file generated with both programs.
Since this is more a debugging option, it's not listed in the help, just here.

== Missing Option ==
This option alerts translators to untranslated strings. For each language (other than English, the master) it generates a file named "missing_<language>.txt, with lists of missing UTF8 strings. Each line has the quoted #str_<id> and quoted content, but not comments.

===What's Considered "Missing"?===
This categorization was established in PL and now mimicked in PLUS.

''If for a given master [English] #str_<id>, there's no matching #str_<id> in the target language.''

It's "missing", unless there's a (hard-coded) exception:

* The master string's content is in the "master_non_translatable" group, namely:
** An empty or whitespaces-only string.
** "TDM" or "The Dark Mod".
** A prefix designating a function key ("F") or port ("AUX" or "JOY") followed by 1 or 2 digits.
** A special numeric format like "320x400;640x480" or "123;345" or "1x;2x".
* The master string's content is a font selector, i.e., beginning with "fonts/".
* The #str_<id> has a numeric <id> within a "master_id_non_translatable" range. Just one range, 02460 – 02490, is so reserved, for language names.

''If the #str_<id> in English and the target language have identical content (not counting comments)''

It's "missing", unless there's an exception:

* The target line has a "//" comment indicating "stays the same"
* The "master_non_translatable", font selector, or "master_id_non_translatable" exclusions apply.

''Otherwise, it's not missing.''

That covers this additional case, where for the matching #str_<id> in English and the target language, there's different content (ignoring comments). Surprisingly, this is considered "not missing" even when the English content exists and the target language content is an empty string.

Rarely, the master content can be empty, but the translated string may or may not be. An example is #str_02313, representing an optional second line needed for some languages.

== CSV Options ==
These options read the contents of all.lang and rearrange them for export as a comma-separated-values "tdm_all_lang.csv" UTF8 file in the "strings" folder. The options have different generated row order:

-csv Rows sorted by #str_<id>; seriously buggy ordering in PL, works in PLUS.
-csv-unsorted PLUS only. Keeps row order of [English] in all.lang

The exported CSV file can then be imported into other tools for translators, e.g., Excel spreadsheets. Be aware as you process this data further: maintaining the UTF8 (or other Unicode) encoding ensures character integrity.

=== Generated CVS File Format ===
The first line of the file has the field (aka column) headers, with languages in alphabetic order:

ID,catalan,czech,danish,dutch,english,french,german,hungarian,italian,polish,portuguese,romanian,russian,slovak,spanish,swedish,turkish,comment
There are 19 comma-separated fields here, so the results is very wide. (Recall in a spreadsheet, you can hide columns not of current interest.)

Broadly, the .csv format comes in different variants. Traditionally, as here, comma is the separator. If a field contains a comma, the field overall is wrapped in double quotes. PL also so wraps if there's a contained double-quote, colon, or semi-colon. PLUS mimics that policy. PL unfortunately only considers the language fields for wrapping. PLUS goes a bit further, to consider the "comment" field.

So, after the header each subsequent line has fields separated by commas, where:

* The first field, "ID", has #str_<id>. Unlike in all.lang, there are no enclosing double quotes.
* Remaining fields have translations. As expected, language fields are in the alphabetic header order shown, not necessarily the [language] section order in all.lang. English is in field 5. A field might be empty, have translation text, or have a copy of the master [English] text. (see "What's in Each Language Field" below). There are enclosing double quotes as needed.
* The last field has any comment from the master {English], beginning with "//". If there was no comment, a trailing comma ends the line.

An example row with some empty fields, for the English word "Error", with no comment:

#str_02000,Error.,,Fejl,,Error,Erreur,Fehler,Hiba,Errore,Błąd,Erro,Eroare,Ошибка,Chyba,,,Hata,
Comments on source lines in sections other than [english] are not included.

=== Sorted and Unsorted Row Orders ===

With the -csv option:

* For PLUS, the row order is sorted by #str_<id>.
* While PL intended the row order to be sorted by #str_<id>, the actual sorting is scattershot. (A cause may be the more-recent presence of numerous non-numeric IDs. The sort uses a custom comparator, which knows only about numeric IDs. Other IDs are "tied" in order, not good for many sort algorithms. The Perl code that writes the <language>.lang files uses a better comparator.) The workaround is to import the data into your spreadsheet (keeping UTF8 encoding) and do row sorting there.

With the -csv-unsorted option [PLUS only]:

* Sometimes, it is more helpful to have rows in the same order as in the master [english] section of all.lang, e.g., not necessarily sorted; so perhaps meaningfully grouped. (Caution: in all.lang, there is sometimes a preceding full-line comment that describes a given grouping. That will not be present in the .csv file.)

=== What's in Each Language Field ===
As discussed above, a field will have enclosing double quotes as needed.

The master "english" field, will simply have the [English] content (which could in rare cases be empty).

The situation for other languages is more complex. PL appears, in its separate csv implementation, to be following a middle course, between:
* the "always use translation if available; otherwise English" policy for <language>.lang generation.
* the categorization of the Missing Option.

To make clear the difference, we repeat the Missing Options description, but with '''lines crossed out''' below. (PLUS follows what PL does here, but FYI, there is commented-out code that could implement the crossed-out conditions.)

A field considered "missing" will be empty (e.g., between 2 commas).

''If for a given master [English] #str_<id>, there's no matching #str_<id> in the target language.''

It's "missing", unless there's a (hard-coded) exception:
* The master string's content is in the "master_non_translatable" group, namely:
** An empty or whitespaces-only string.
** "TDM" or "The Dark Mod".
** A prefix designating a function key ("F") or port ("AUX" or "JOY") followed by 1 or 2 digits.
** A special numeric format like "320x400;640x480" or "123;345" or "1x;2x".
* <s>The master string's content is a font selector, i.e., beginning with "fonts/".</s>
* <s>The #str_<id> has a numeric <id> within a "master_id_non_translatable" range. Just one range, 2460 – 2490, is so reserved, for language names.</s>

In this case, if it's not missing, the '''master string's content''' will be used.

''If the #str_<id> in English and the target language have identical content (not counting comments)''

It's "missing", unless there's an exception:
* <s>The target line has a "// comment" indicating "stays the same".</s>
* The "master_non_translatable", <s>font selector, or "master_id_non_translatable"</s> exclusions apply.

In this case, if it's not missing, the '''translated string content (same as master string's content)''' will be used. As indicated, any "stays the same" phrase in the line's comment within the [language] section is ignored.

''Otherwise, it's not missing.''

The '''translated string's content''' will be used. This is the normal "translation provided" case, where for the matching #str_<id> in English and the target language, there's different content (ignoring comments). Note that if English content exists but the target language content is an empty string, while this categorization would call it "not missing", it still has the same result: nothing between the commmas.

=== Differences in Comments between PL and PLUS ===
As noted above , PLUS will enclose the comment field in double quotes if needed. Also, if the comment field contains any unescaped double-quotes, they are backslash-escaped.
PL will do none of that. This is a bug. When the .csv file is imported into a spreadsheet, extra spurious columns may result, requiring manual fix-up.
Also, there is a difference in handling of how characters appear in comments. PLUS will preserve UTF8 characters. PL will replace characters not in ISO-8859-1 with "?" (resulting in the same appearance as in english.lang).

== Charstats Option ==
Creating bitmap font glyphs can be a time-consuming process. This option provides information to suggest, among European (i.e., non-ASCII, non-Cyrillic) characters, which ones should take priority in that process, based on what translators have provided to all.lang.

The results go to the console. PL and PLUS formats differ. PL groups compactly by "Top 5", "Top 10", and so on, and is not particularly Unicode-aware.
PLUS gives each character its own line, with rank and additional data. (And the output here is in utf8 form, better viewed in Windows Terminal than the traditional console. Or pipe to a text file that, e.g., Notepad can treat as UTF8.) Example output:

Non-ASCII UTF8 characters in 'all.lang' across all languages except [Russian],
by descending frequency. (Excludes characters in comments.)

Rank, unicode codepoint, utf8 char, frequency (i.e., count out of 13563 total listed)

1 U+00e1 á 1504
2 U+00e9 é 1420
3 U+00ed í 1099
4 U+0131 ı 1075
5 U+00fc ü 755
6 U+010d č 644
7 U+00f3 ó 498
8 U+00f6 ö 418
9 U+00fa ú 407
....
93 U+0152 Œ 1
94 U+0158 Ř 1
95 U+0179 Ź 1

== Ranges Option and Holes Option ==
Traditionally, #str_<id>s had only 5-digit numeric values. When a new string needed to be added (i.e., to the [English] master), it was helpful to know what numeric ranges were already fully in use, and conversely, what ranges are unoccupied, dubbed "holes". With these options, that info gets reported to the console. Note that for PL, "holes" reports only if "ranges" is not given as an option. PLUS removes that restriction.
PL processes and reports <id>s in [English] listing order; if that is non-monotonic, this can cause anomalies for the "holes" output. To fix that, PLUS does a pre-sort into monotonic order.
PL and PLUS formats differ slightly. An example PLUS output for "-ranges":

There are 48 occupied numeric #str_ ranges in [English]:

1000-1019 (with 20 entries)
1050-1062 (with 13 entries)
1500-1503 (with 4 entries)
2000-2016 (with 17 entries)
...
8980-8988 (with 9 entries)
10000-10162 (with 163 entries)
10180-10185 (with 6 entries)

Also, there are 54 non-numeric #str_ entries.

In the last line, you see that, unlike PL, PLUS is aware of non-numeric <id>s, but just reports them as a total.
An example PLUS output for "-holes":

There are 44 unoccupied numeric #str_ ranges (aka holes) in [English]:

0-999 (with 1000 openings)
1020-1049 (with 30 openings)
1063-1499 (with 437 openings)
1504-1999 (with 496 openings)
....
8989-9999 (with 1011 openings)
10163-10179 (with 17 openings)
10185-19999 (with 9814 openings)

The range from 20000-99999 is reserved for FMs. Using #str_<id> in that range in all.lang will trigger a fatal error (with the –range or –hole option). (See also the FM Option.)

== FM Option [PLUS only] ==
By default, when either the -ranges or -holes option is in effect, the valid range for #str_<id> numeric values is enforced by PLUS as 0-19999. If you are using this for FM strings, select this option to make the valid range 20000-99999.

''These days, many but not all main menu #str_<id>s contain a substring "_menu_". There could be future enforcement of alphanumeric substrings.''
== Details about Main File Formats and Processing ==

=== All.lang File Input Format ===
The file begins with a preamble (in C-style comment form) of notes for translators, some of which we restate here. Then an opening "{" by itself, followed by a series of language sections. Each starts with a line with one of these headers (shown in the order currently seen in the main menu all.lang file):

[English]
[German]
[French]
[Italian]
[Spanish
[Polish]
[Romanian]
[Russian]
[Portuguese}
[Czech]
[Hungarian]
[Slovak]
[Swedish]
[Danish]
[Dutch]
[Turkish]
[Catalan]

Case of the language name doesn't matter, nor does order in which sections are listed. But it is a convention to list English first. After the header comes a series of convertible lines and comment lines, as discussed in next sections. The last line of the file has the closing "}".

=== Converting Each Line ===
Within any particular language section of all.lang, a convertible line will have in this order:

# A #str_<id>, in double quotes, where <id> is an unsigned integer, or a string composed of ASCII characters a-z, A-Z, 0-9, or underscore. Preferred for the latter are all lower case with underscores as word separators. Camel-case is tolerated, but not spaces or dashes. Ignoring the "#str_" prefix, the <id> must be no less than 5 and no more than 63 characters long. Leading zeros should be used to pad a numeric <id> to 5 digits. [Note: program i18n.pl possibly deals only with numeric <id>s.]
# The language-specific UTF8 <string content>, in double quotes
# An optional comment beginning with "//". The next section covers overall treatment of comments.

These are led and separated by whitespace. A leading tab is normal, with tab separators.

No particular ordering of #str_<id>s is required, though ordering numeric <id>s (at least within sub-groups) is desirable.
==== Duplicates Across Lines Within a Section ====
If a particular <id> value appears more than once in a section, the last value is the effective one. A console warning will generally occur during parsing, in the case of PLUS like:
Warning - #str_02518 redefined within [english]...
from: malformed
to: 100

In the [English] section, there might be separate <id>s with the same content. This will generally cause a warning, in the case of PLUS like:
Caution - These strings have the same content ('Master'): #str_08206, #str_03008

To avoid the latter warning, a group of duplicates can be assigned a group number and hard-coded in the "master_double_exceptions" list. Only one group of ten members is so defined currently, those with a required empty string as content. More generally (says a PL comment): "Sometimes it can make sense to have two different strings as when they are translated into different strings in another language. A [theoretical] example would be "Saw" (I saw something, ich hab etwas gesehen) and "Saw" (Saw, Säge)."

==== Substituting English when No Translation ====
Ideally, a #str_<id> in the master [English] section has a match in a target language's section. Then the translated content will always be used for encoding and listing in the <language>.lang file. If no match, the English content is substituted. (Note that only a subset of these substituted strings will categorized as "Missing" if the -missing option is used. Also note that the substitution policy is slightly different with the -csv option.)

==== Conversion Differences between PL and PLUS ====
* To do encoding, PL uses the Perl Encode module, that can autoload language-specific encode/decode tables.
* In the C++ implementation, source file "UTF8_8859_convert.cpp" includes similar (albeit custom) tables for the codepages TDM supports. The overall approach is convert from UTF8 to UTF16, then to the target ISO encoding. That process does not use <locale> facets (which are problematic for our purposes), but standard C++ library "codecvt_utf8_utf16" and "wstring_convert" capabilities.

=== The <language>.Lang File Output Format ===
* A preamble states the language name and specific ISO encoding.
* This is followed by the "#str_<id> ..." lines; sorted in alphabetic order; <id> in numeric form will be listed before those in alphabetic form. Among the latter, an upper case letter will sort before all lower case letters.
* Trailing "//" comments on "#str_<id>" lines from all.lang are preserved.
* Comments of the form /*...*/ in all.lang are skipped, whether spanning multiple lines or part of a single line.
* Blank lines, or lines with only whitespace or a "//" comment, are likewise skipped. The latter comments typically contain headers to organize groups of items in all.lang, but that organization is not retained, replaced by alphanumeric ordering as mentioned.

==== Output File Differences between PL and PLUS ====
These differences are not thought to have functional implications:

* The first line of the preamble will differ unless PLUS's -old_preamble option is used.
* Between a string content and any comment, PLUS preserves tabs and spaces found in all.lang, while PL substitutes two tabs. This is means that simple file comparison programs (like Windows "fc", even with /T or /W options) will find lots of trivial differences. It is suggested you use a more sophisticated comparison tool, for instance, Notepad++ with the ComparePlus plugin and "Ignore changed spaces" selected.

== Notes on PLUS Internals ==
A hand-crafted conversion from a static analysis of PL, PLUS preserves many variable names, some reimagined as functions. Befitting a straightforward conversion, it offers a procedural, C-like style, without much in the way of a class hierarchy, overarching object-oriented design pattern, or advanced C++ features. (This may be of benefit if part or all of its functionality is ever integrated into the TDM engine and/or DR.)
Not much effort was spent on performance optimization. However, as a compiled language, it will of course run much faster than PL. Also, the C++ implementation avoids use of regular expressions, which are heavily featured in PL and are notoriously slow and also hard for most coders to read.

Platform-independent C++ standard-library structures like vectors, (ordered) sets, maps, and multimaps are employed. However, to do the UTF8 to ISO conversions, a Windows-specific approach is taken, to convert via unencoding from utf8 to wide characters and then re-encoding to target ISOs. (While it is possible to do such conversions entirely within 8-bit characters, the resulting code is a puzzle box, best left to third-party libraries.) Instead of using a third-party library, the encode/decode implementation here includes use of the "deprecated" C++ standard "codecvt" feature; while deprecated, the C++ standard committee has not (as of 2025) come up with a viable replacement.

Like PL, PLUS has some DEBUG statements defined (requiring recompile for C++). These reflect specific concerns during development and testing and are of limited general interest.

== Downloads ==
For PLUS v1.1 of 2025, July 16 (mainly adds Catalan as a supported language)

* [https://drive.google.com/file/d/1R_qajkfq5_drIGEMYQ8ahpJwfN1LdkiT/view?usp=sharing gen_lang_plus_source_v1.1.zip]. This is a Visual Studio project. Includes open-source license.
* [https://drive.google.com/file/d/1kj_zE9VN7l1DMztnOHx-UaNbIAECIE6M/view?usp=sharing gen_lang_plus.exe]

For PLUS v1.0 of 2025, Feb 28:

* [https://drive.google.com/file/d/1V_FSMEBYsinXPMKlH3_OmzcS8f1zjVeL/view?usp=sharing gen_lang_plus_source_v1.0.zip]. This is a Visual Studio project.
* [https://drive.google.com/file/d/1xsas9kZ-6tRdNdFhKHS736xYK5-aYGMg/view?usp=sharing gen_lang_plus.exe]

== See Also ==
The Perl program "i18n.pl" contains similar functionality for FM-specific strings, but also parses and edits the FM .map file, so is considerably more complicated.

Inventory

2026-05-30T22:24:42Z

Geep: /* Length of Inventory Display Names */ New section added

This article describes how to set up inventory items and how they can be given to an entity. An entity's inventory can be seen as some sort of "container" for various items. Inventory items are distinguished by their category, such as ''Tools'', ''Maps'', ''Potions'' and ''Weapons'' (yes, a weapon is also a special kind of inventory item). All entities can have an inventory, even though it may only make sense for AI and the player to actually have one. Also included is a script interface, so that a mapper can interact with the inventory in a more sophisticated way, if the default behaviour is not sufficient.

== Definitions ==

The spawnargs can be either set in the def file as a default, or in the map file to override settings for specific entities. Naturaly this also means that they can be manipulated by scripts as well.

'''IMPORTANT!''' When items are put into inventory they remain in the map in their original location, but are hidden and will therefore 'disappear'. If this doesn't work, then the item will stay visible. This is a intentionally so, to make the mapper aware of the problem. Check the console and/or enable the inventory logclass in the darkmod.log file to see what went wrong.

There are several terms and types of items that can be used in the inventory:

* '''Anonymous items''' An anonymous object means that it will not show up as an item in the inventory. Examples are gold coins and all the other (mostly loot) items that are collected but not being used individually. In this case they only count for the total of loot and are discarded afterwards. Anonymous items also can not be dropped after they are placed into the inventory because they essentially no longer exist. For the loot count it obviously doesn't matter wether an item is anonymous or not, as all are added up into the loot categories. The same holds for ammonition (arrows). These get added to the weapon's ammo and are removed from the map.

* '''Stackable items''' These are items that can be stacked in the inventory. This means that the player can acquire multiple instances of such items, but only one entry is shown in the inventory with a counter of how many currently are available. An example would be a health potion. The player can possess more than one health potion at a time and this would be indicated by the counter on the HUD. Stackable items are identified by setting the stackable property. They also must always use the same name and category. If this doesn't match, they are considered to be different. This also allows for dealing out i.e. fake health potions which have no effect or deal damage instead (as an example).

* '''Category''' Each item has a Category, which is used to group items. This allows the player to faster scroll through the inventory because he doesn't have to cycle through all the individual items. For example a category would be 'Readables' where books and scrolls are stored, and another Category would be 'Tools' where lockpicks and other items can be stored. Note that the actual category names are entirely up to the mapper. It doesn't have any consequence as to the playability and is only a convenience for the player. The inventory category is briefly displayed on the player HUD when cycling through the items.

* '''Cursor''' ''(This is coding-related information)'' An inventory can have multiple cursors. Each cursor can point to a different place in the same inventory, and can restrict the movement to certain categories. This way, you can implement different HUDs or GUIs which can show different parts of the inventory in different places even though all the items are in one single inventory. Weapons are handled this way; a separate cursor is used which is only allowed to cycle through the weapon category.

== Spawnargs ==
;'''<tt>inv_name</tt>''' | string '''[required]'''
:Specifies the name the object should display when it is activated in the inventory. Keep in mind that the display name and the category together are used to determine whether two items are of the same type. This is important to determine whether items can be "stacked". Both '''inv_name''' and '''inv_category''' must match.
:Example: <tt>"inv_name" "Health Potion"</tt>

;'''<tt>inv_category</tt>''' | string '''[required]'''
: Specifies the category that the object should be filed under.
:Example: <tt>"inv_category" "Potions"</tt>

;'''<tt>inv_icon</tt>''' | string (D3 path to icon file)
:Points to an icon that is to be displayed on the player HUD when the object is selected in the inventory. (This can also point to a shader name.) Note that you don't need to specify the file extension.
:Example: <tt>"inv_icon" "guis/assets/hud/inventory_icons/icon_health_potion"</tt>

;'''<tt>inv_stackable</tt>''' | [0/1]
: Determines whether an item can be stacked on top of other items of the same type. An example would be the health potion item. The player can pick up more than one health potion, but in the inventory he will only get one item with a counter. Note that loot items need not to be stackable, they are handled separately by special code.

;'''<tt>inv_item_id</tt>''' | string
:This key can be set by the mapper to a value of his or her choice. This is needed if the mapper wants to address specific items or groups of items in order to implement custom behaviour, even if the <tt>inv_name</tt> is the same for this group of items. For example, a mapper can create a fake health potion which shows up in the inventory just like a regular one. If the mapper desired, he could set up a script to check for this exact potion and trigger custom behaviour when the item is used.

;'''<tt>inv_count</tt>''' | integer number
: Defines how many instances of an item is to be added to the inventory. Applies only to items with <tt>inv_stackable</tt> set to 1. Non-stackable items have always an item count of 1 and this argument is ignored. As an example, the mapper could set up a stack of health potions as single entity (some sort of quiver) which immediately adds 5 potions to the player's inventory.

;'''<tt>inv_droppable</tt>''' | [0|1]
:If set to 1 the item can be dropped into the map by the player. This will not work for anonymous items (loot, ammo), since their entity will be removed from the map after they had been put into the inventory.

;'''<tt>drop_to_hands</tt>''' | [0|1]
:If set to 1 (default) the item drops to the hands (grabber manipulator) of the player instead of to the ground. Set to 0 and the item drops directly to the floor when dropped.

;'''<tt>inv_loot_type</tt>''' | [ 0 | 1 | 2 | 3 ]
::* 0 = No lootitem (default)
::* 1 = Jewelry/Gems
::* 2 = Gold
::* 3 = Goods
:This has to be set in order to define what kind of item it is and if it is a loot item, which category of loot it should account for. Note: it's not possible to choose other values (e.g. loot type = 4), the code will probably crash.

;'''<tt>inv_loot_value</tt>''' | integer
:Determines the amount of loot this item accounts for. This spawnarg is only applicable for items with a non-zero <tt>inv_loot_type</tt>.

;'''<tt>inv_ammo_amount</tt>''' | integer (default is 0)
: Determines whether this item is an ammo item and how much ammonition this item represents. When this argument is 0, the item is not recognised as ammo. Ordinary ammonition items like [[atdm:ammo_broadhead]] have <tt>inv_ammo_amount</tt> set to 1, but it's perfectly valid to set it to higher values for items like quivers. Don't forget to add the <tt>inv_weapon_name</tt> spawnarg, which is needed by the code to determine which weapon this ammo belongs to.

;'''<tt>inv_weapon_name</tt>''' | string
: This spawnarg applies to weapon and ammo items. Each weapon must have a unique <tt>inv_weapon_name</tt>, like "broadhead" or "blackjack". This weapon name is used to determine which weapon an ammonition item is belonging to. If the <tt>inv_weapon_name</tt> is missing on ammonition, it cannot be recognised as loot (a warning is emitted to the console and the log).

;'''<tt>inv_use_on_frob</tt>''' | [0|1] (default is 0)
: When this spawnarg is set to 1, it can be used just by hitting the "frob" button (of course it must be selected in the inventory). The code then attempts to "use" this item on the highlighted entity in front of the player. The system is still in the works, so this information might not be fully accurate.

;'''<tt>inv_map_start</tt>''' | [0|1]
:Determines wether this object should be automatically moved to the inventory at map start.

;'''<tt>inv_target</tt>''' | string (entityname, optional, defaults to "player1")
:If the <tt>inv_map_start</tt> argument is set to "1", this defines the name of the entity that should receive it, otherwise the value is ignored. To give an item to the player, you would use <tt>player1</tt> as the name (which is the default value anyway).

;'''<tt>inv_hud</tt>''' | string (D3 path to .gui file)
: If this key is set it should point to a GUI file, which defines the hud for this particular item. As an example, you can look at the file tdm_loot.hud, which implements a custom hud that does not use the regular inventory item HUD. The mapper is responsible to maintain the state for such an item on his own. In order to do this, there is an initialization message sent to the specified script and other messages as well like selecting or deselecting an item. In order to make this work, the mapper must set up the correct scriptobject and add a few events to it. An example description of how to operate a custom HUD will be described in the scripting section on this article.

;'''<tt>inv_hud_layer</tt>''' | integer (layernumber)
: If a custom hud is used for an item by setting the key <tt>inv_hud</tt>, this key can be set to specify a layer number the custom hud should be displayed on. Normally this value can be set to 0 or left blank when using the default screen for the player, but for huds on other objects in the map, this might be needed.

;'''<tt>inv_persistent</tt>''' | [0|1] (default is 0)
: If this is set to "1", the item can be taken to the next map. This is useful for designing campaigns, where important items or weapons can be taken to the next level.

;'''<tt>inv_lgmodifier</tt>''' | int (default is 0, maximum is DARKMOD_LG_MAX = 32)
: This can be used to modify the lightgem brightness when this item is selected in the inventory. Useful for weapons like the fire arrow.

;'''<tt>inv_movement_modifier</tt>''' | float | default is 1, must be positive
: This can be used to slow down the player when this item is equipped (e.g. for weapons like the shortsword). This value is multiplied on the maximum movement speed.

;'''<tt>inv_no_pickup_message</tt>''' | [0|1] | default is 0
: Setting this to 1 disables the "pick up message" when this item is put into the player's inventory.

== Length of Inventory Display Names ==
The inv_name needs to be relatively short. If it is too long, when displayed in the lower right screen corner, rightmost words will be clipped or missing. This starts to become a concern at roughly 18-20 characters (including spaces). To worse-case test this, go to the HUD Size/Opacity "Adjust" page (under Settings > Video > General), leave the "Icon Size" at the default, but maximize "Weapon/Item Text Size".

Fixes for this are:
* simply shorten the name. For instance, it may not be necessary to call an item "Treasure Chest Key", if the icon makes it obviously a key, so "Treasure Chest" would do.
* Manually force the display name to two lines, by inserting a "\n" into the inv_name string (or if using #str_ translations, into the corresponding content in the all.lang file and its offspring). The engine and inventory display gui collaborate on this, but only 2 lines at most. Cautions: Don't expect automatic word-wrap from 1 to 2 lines. And either line could still be individually clipped if too long.

If you are providing i18n translation strings, review every language's inventory name lengths. Non-English phrases are often longer than English.

== Default equipment for map start ==

This describes how to give items to the player at map start time, but the same mechanism can be applied to any other AI (or entity for that matter) as well.

* First create your object in the editor, just like you would if you wanted to put it in the map. Choose Create Entity and select the inventory item of your choice (a health potion for example). Place it where you like, but not outside in the void.
* Set the key <tt>inv_map_start</tt> on the object entity to the value 1.
* (Optional) Set the key <tt>inv_target</tt> to the name of the entity you would like this item to go to.

The object will be moved to the target entity's inventory right at map start (and will be hidden or removed). The player will not be able to see the item (unless there was a mistake in the setup).

== Inventory CVARs ==
The following cvars can be used to modify the behaviour of some inventory properties. Some of them are probably only of interest to modders, while others are also of interest to players and might be added to a customization menu.

;'''<tt>tdm_inv_hud_file</tt>''' | string | default "guis/tdm_inv.gui"
:Specifies the gui file that should be used for the inventory. this can be changed for mods, that wish to implement a different GUI, or provide alternative skins for the player.

;'''<tt>tdm_inv_loot_item_def</tt>''' | string | default "atdm:inv_loot_info_item"
: Specifies the entityDef that should be used for the loot info slot in the inventory. This entityDef holds the references for the loot HUD.

;'''<tt>tdm_inv_hud_pickupmessages</tt>''' | [0|1] | default is 1
:If set to 1, the HUD is displaying the item the player has just picked up.

;'''<tt>tdm_inv_loot_sound</tt>''' | string | default "frob_loot"
: Specifies the default path to the soundfile that is played when loot is aquired. Note that this can be overriden on a per item level, and wont have an effect for such items. ''(greebo: Should be removed)''

;'''<tt>tdm_inv_use_on_frob</tt>''' | [0|1] | default is 0 (for now)
:When set to '1' the code attempts to use the currently selected inventory on frob, provided the selected item supports this action.

;'''<tt>tdm_inv_use_on_frob_visual_feedback</tt> | [0|1] | default is 1
:When set to '1' the HUD is giving visual feedback when the currently highlighted item is used.

=== Related CVARs ===
;'''<tt>tdm_hud_opacity</tt> | float [0..1]
:Defines the opacity of the HUD GUIs, also affects the lightgem and the weapon HUD.

== Key bindings ==

For inventory key bindings see [[Bindings_and_User_Settings#Inventory_Related]]

== Scriptsupport ==
The following events are available for scripters. These events can be called on any entity (as every entity has an inventory), but I assume for 99% of the cases, you will want to use these on <tt>$player1</tt>.

;<tt>scriptEvent float getLootAmount(float Type);</tt>
:Returns the amount of loot for the given type (e.g. LOOT_GOODS). There are a few loot constants defined in <tt>tdm_events.script</tt> file. Pass LOOT_TOTAL to return the sum of all loot types.
:*LOOT_TOTAL
:*LOOT_JEWELRY
:*LOOT_GOLD
:*LOOT_GOODS

;<tt>scriptEvent float changeLootAmount(float type, float amount);</tt>
:Changes the loot amount of the given Type (e.g. GOODS) by <amount>. The new value of the changed type is returned (e.g. the new GOODS value if this has been changed). Note: The LOOT_TOTAL type can't be changed and 0 is returned.

;<tt>scriptEvent void addInvItem(entity inv_item);</tt>
:Adds the given item to the inventory. Depending on the type, the passed entity will be removed from the game (as for loot items) or hidden. If the item couldn't be added, a warning is emitted to the console.

;<tt>scriptEvent float replaceInvItem(entity oldItem, entity newItem);</tt>
:Replaces the entity <oldItem> with <newItem> in the inventory, while keeping <oldItem>'s inventory position intact.
:Note: The position guarantee only applies if <oldItem> and newItem share the same category. If the categories are different, the position of <newItem> is likely to be different than the one of <oldItem>.
:Note that <oldItem> will be removed from the inventory. If <newItem> is the $null_entity, <oldItem> is just removed and no replacement happens.
:Returns: 1 if the operation was successful, 0 otherwise.

;<tt>scriptEvent entity getNextInvItem();</tt>
;<tt>scriptEvent entity getPrevInvItem();</tt>
:Cycles the standard cursor to the next/prev inventory item.
:Returns: the item entity pointed to after the next/prev operation is complete.

;<tt>scriptEvent float setCurInvCategory(string categoryName);</tt>
:Sets the inventory cursor to the first item of the named category.
:Returns: 1 on success, 0 on failure (e.g. wrong category name).

;<tt>scriptEvent entity setCurInvItem(string itemName);</tt>
:Sets the inventory cursor to the named item.
:Returns: the item entity of the newly selected item (can be the $null_entity).

;<tt>scriptEvent string getCurInvCategory();</tt>
:Returns the name of the currently highlighted inventory category.

;<tt>scriptEvent entity getCurInvItemEntity();</tt>
:Returns the currently highlighted inventory item entity.

;<tt>scriptEvent string getCurInvItemName();</tt>
:Returns the name of the currently highlighted inventory item (the one defined in <tt>inv_name</tt>).

;<tt>scriptEvent string getCurInvItemId();</tt>
:Returns the name of the currently highlighted inventory item (the one defined in <tt>inv_item_id</tt>). Most items will return an empty string, unless the "inv_item_id" is set on purpose.

;<tt>scriptEvent string getCurInvIcon();</tt>
:Returns the icon of the currently highlighted inventory item.

;<tt>scriptEvent void changeInvItemCount(string name, string category, float amount);</tt>
:Decreases the inventory item stack count by amount. The item is addressed using the name and category of the item. These are usually defined on the inventory item entity (<tt>inv_name</tt>, <tt>inv_category</tt>). Amount can be both negative and positive.

;<tt>scriptEvent void changeInvLightgemModifier(string name, string category, float modifier);</tt>
:Sets the lightgem modifier value of the given item. Valid arguments are between 0 and 32 (which is the maximum lightgem value).

;<tt>scriptEvent void changeInvIcon(string name, string category, string icon);</tt>
:Sets the inventory icon of the given item in the given category to <icon>.

=== Example ===
A short example of the above script events in action is the lantern script:
// Set the icon to the "on" icon
userEntity.changeInvIcon(getKey("inv_name"), getKey("inv_category"), getKey("inv_icon_on"));
The first call is retrieving the <tt>inv_name</tt> and <tt>inv_category</tt> spawnargs from the lantern entityDef and takes them as argument for te <tt>changeInvIcon</tt> call. The <tt>inv_name</tt> and <tt>inv_category</tt> are necessary for the code to lookup the item in the player's inventory. The third parameter defines which icon the lantern inventory item should have from now on.

== Custom HUDs ==
It is possible to implement a custom HUD for each inventory item. Examples for inventory items with custom HUDs are the player compass and the loot info item. This describes how to set up a custom HUD for your item.

# First off, you need an entityDef with your inventory item. Look at <tt>atdm:playertools_compass</tt> for an example.
# Your inventory item entity needs to have its own script object, so you'll need to name that in your entityDef using the "scriptobject" spawnarg.
# The scriptobject (which will be defined in a .script file) needs to implement a small set of functions which are invoked by the code when the item is initialised, selected or de-selected.

=== Set up the entityDef ===
Again, the compass is given as an example:
entityDef atdm:playertools_compass
{
"inherit" "atdm:playertool"
"spawnclass" "idStaticEntity"

"editor_usage" "Compass"

"model" "models/darkmod/player_equipment/compass.ase"
"scriptobject" "playertools_compass"

"inv_name" "Compass"
"inv_category" "Compass"
"inv_map_start" "1"

"inv_hud" "guis/playertools/compass.gui"
"inv_hud_layer" "11" // greebo: Readables are on layer 10
"inv_icon" ""
"inv_droppable" "0"
}
The compass is set up like any other inventory item - the important thing is to specify the <tt>inv_hud</tt> and <tt>inv_hud_layer</tt> spawnargs. The <tt>inv_hud</tt> argument is pointing to a sepcific GUI file, which will be displayed when the inventory item is selected by the player. The <tt>inv_hud_layer</tt> defines on which layer the GUI is being drawn (GUIS with higher overlay numbers are drawn after the ones with lower numbers).

Also note that <tt>scriptobject</tt> spawnarg which points to the script class, in this case <tt>playertools_compass</tt>. See the next chapter for information about how to set this up.

=== Set up the scriptobject ===
As next step, you'll need to add a custom scriptobject which defines the methods to be called by the SDK code. Create a .script file and define a scriptobject with the following methods:
/*
* Compass scriptobject, derives from player_tools
*/
object playertools_compass : player_tools
{
// greebo: Gets called upon addition to the inventory
void inventory_item_init(entity userEntity, float overlayHandle, string overlayName);

// Gets called when the player switches to another inventory item
void inventory_item_unselect(entity userEntity, float overlayHandle);

// Gets called when this item is selected in the inventory
void inventory_item_select(entity userEntity, float overlayHandle);

// Gets called to update the HUD (not each frame!)
void inventory_item_update(entity userEntity, float overlayHandle);
};
As you can gather from the comments, the various functions are called by the SDK code on certain occasions. The <tt>userEntity</tt> argument always defines the entity which holds the inventory item, which is the $player1 entity in almost all cases. The second parameter <tt>overlayHandle</tt> defines the GUI handle which can be used to set the GUI state variables of the custom HUD. These depend on your implementation, of course. I won't go into the details here (you can look at the actual files in the scripts/ folder), but as an example I can pick the <tt>inventory_item_select()</tt> method of the compass scriptobject:
void playertools_compass::inventory_item_select(entity userEntity, float overlayHandle)
{
_overlayHandle = overlayHandle;

// Disable the default inventory
userEntity.setGuiFloat(userEntity.getInventoryOverlay(), "Inventory_ItemVisible", 0);

// Make the compass GUI visible
userEntity.setGuiFloat(_overlayHandle, "CompassVisible", 1);

// Start a new thread
_updateThreadNum = thread updateLoop(userEntity);
}
The interesting part is how to set the GUI state variables, which is easy: just use the <tt>setGui***</tt> methods on the <tt>userEntity</tt> (usually the player), passing the overlayHandle along to specify which HUD you are addressing.

===Set up a custom GUI if needed===
As mentioned above, you can define key ''inv_hud'' to point to a custom .gui file. For example, the special compass GUI is further considered in conjunction with its implementing architecture in [[GUI Scripting: RenderDef]]. Also, starting in TDM 2.06, there are a richer set of user settings that affect inventory HUD displays. If your custom item provides its own GUI, consider incorporating these (e.g., "gui::HUD_Opacity", "gui::smallTextSize"). For examples, see the "Extra: Adding a Custom GUI" section at this article's end, or contents of files tdm_hud.gui, tdm_inv.gui, or tdm_loot.gui in tdm_gui01.pk4\guis\.

== Setting up Weapons ==
Setting up weapons is not that hard actually from the entityDef point of view. The hard part is to get the models and animations right, which is mostly artwork. However, this short chapter should explain how the various entityDefs are connected to each other.

=== Weapon ===
First of all, you'll need a weapon entityDef, one that is inheriting from <tt>atdm:weapon_base</tt>. The entityDef needs a unique <tt>inv_weapon_name</tt> serving as identifier for ammunition and scripting. The <tt>atdm:weapon_base</tt> carries some editor_* spawnargs which explain the various options you have to "configure" your weapon (like whether ammunition is required, or whether it is a toggleable weapon, or the scriptobject, etc.).

Let's assume you set up a weapon with ammunition (i.e. the weapon carries the spawanrg <tt>"ammo_required" "1"</tt>). In this case you'll need a couple of additional entityDefs, namely ''ammo'', ''attachment'', ''projectile'' and ''result'' entities.

=== Ammo ===
For weapons requiring ammunition, you'll need to add the <tt>def_ammo</tt> spawnarg, which should point to an entityDef inheriting from <tt>atdm:ammo_base</tt>. This links the weapon to the correct ammunition entityDef. To link back the ammo to the weapon, add the <tt>inv_weapon_name</tt> spawnarg to the ammo entityDef pointing back to the weapon (e.g. "broadhead").

=== The Weapon Attachment ===
Each arrow weapon in TDM needs an attachment entity for display during the bow animations. For instance, whenever the player selects the water arrow weapon and starts to draw the bow string, the entity of type <tt>atdm:attachment_waterarrow</tt> is attached to the bow viewmodel. The name of the attachment entityDef is defined on the weapon with the spawnarg <tt>def_attach</tt>.

=== The Projectile ===
Once the player releases the bow string, the projectile is fired. The <tt>def_projectile</tt> spawnarg on the weapon points to the desired projectile entityDef.

=== The Projectile Result ===
The launched projectile will impact somewhere, and this is the point in space where the so-called ''projectile result'' will be spawned. The projectile entityDef holds the spawnarg <tt>def_result</tt> pointing to the correct result entityDef. The result in turn has to implement the correct script methods which are called by the projectile collision code in the SDK. These script methods on the result's scriptobject will implement the actual behaviour of the arrow (like playing sounds, deploying ropes, etc.).

== How to make inventory items to interact with world objects ==
Kingsal has reported how to use inventory items on items frob-highlighted in the game world. The report is here: http://forums.thedarkmod.com/topic/18505-script-for-placing-the-right-object-in-the-right-place/?p=397333

Consider this scenario:
* The gamer knows that somewhere in the map, there's a skull that must be placed on an altar.
* When the skull is found, frobbing it puts it into the inventory.
* Later, either:
** frob the pedestal altar, which appears to instantly transfer the skull from inventory to atop the altar. (Behind the scene, there are 2 skulls involved: the custom entity dropped from inventory, and a hidden one prepositioned on the altar.)
** drop the skull into your hands (R key), move it above the altar, and drop it there (R key again). (Altar remains frobbable after this, but frobbing does nothing.)

This requires a custom set up for an inventory item you would like the player to use_on_frob when highlighting an object in the world. (While the scenario in this example is placing a skull on a pedestal, there are many different uses/scenarios. There are also several ways to do this. Check out http://wiki.thedarkmod.com/index.php?title=Tool,_Key,_custom_used_by_inventory_actions for another method.)

You will need the def files and script file below.

This assumes you have basic knowledge of creating .def files and .scripts. If not. PM me (kingsal) for help.

===Def File===
Place this in your def file.

//++++++++++++++++++++++++Use Inventory Item++++++++++++++++++++++++++++++
// The inventory_use_item's "inv_name" spawnarg MUST match the "item_name" spawnarg on the Altar.

entityDef inventory__use_item //Change the name if you'd like
{
"inherit" "atdm:moveable_small_base"

//editor junk
"editor_displayFolder" "interactables/special" // Change to a location you'd like it to show up in DR.
"editor_usage" "Custom use-on-frob item"
"editor_color" "0.922 0.039 0.855"

//Model
"model" "models/darkmod/graveyard/bones/skull2.ase" // Change to appropriate model. Should have a collision mesh.
"mass" "10" // If item can be dropped, Set this higher to avoid the player from lobbing it too far.
"friction" "0.7"
"solid" "0"

//Inventory stuff
"inv_name" "custom item name" //Rename it something fun! MUST match the name on the Altar.
"inv_icon" "guis\assets\hud\inventory_icons\skull_inv_icon" // GUI icon.
"inv_droppable" "1" //Allows the player to drop this. Beware they might drop it someplace where it can't be retrieved.
"inv_category" "Custom Items" //Rename this to the appropiate category.
"inv_stackable" "1" //This is only needed if their are multiple of these items that you want to stack in the inventory.

//sound
"snd_acquire" "tool_pickup"
"snd_bounce" "tdm_impact_metal_med_lesser"

}

//++++++++++++++++++++++++Altar++++++++++++++++++++++++++++++

entityDef use_item_altar //Change the name if you'd like
{
"inherit" "atdm:entity_base"
"spawnclass" "idStaticEntity"

//editor junk
"editor_displayFolder" "interactables/special" // Change to a location you'd like it to show up in DR.
"editor_usage" "Altar for placing inventory_use_items"
"editor_color" "0.922 0.039 0.855"

//Model
"model" "models/darkmod/furniture/tables/builder_pedestal01.lwo" //Change to appropriate model
"solid" "1" //Must be solid

//Interaction
"frobable" "1"
"frob_action_script" "use_altar"
"item_name" "custom item name" //This must match the inv_name spawnarg of the custom item
}

===Script===
This is the script that goes in your mymap.script. Or fms/scripts which requires adding the script name to your tdm_custom_script file.

/////////// EVENT SCRIPTS //////////////
//Place this in your fms/maps/ as a mymapname.script.
void use_altar(entity altar)
{

entity curr_item = $player1.getCurInvItemEntity();
if ($player1.getCurInvItemName() == altar.getKey("item_name"))
{
$player1.changeInvItemCount(curr_item.getKey("inv_name"), curr_item.getKey("inv_category"), -1); //Removes item count by one.
altar.activateTargets( $player1 ); //Activates the altar's targets.
altar.setFrobable( 0 ); //Sets to none frobable. One time use. REMOVE THIS TO MAKE RE-USABLE.
altar.startSoundShader ("mage_fireball_impact", SND_CHANNEL_VOICE ); //Play a sound you like!
sys.wait( 1 );
}

}

===Set-up===

By default the custom items can be found in DR under yourfms/interactables/special. Unless you changed the path

1. Add the inventory_use_item and use_item_altar to your map.

2. Be sure to change the "inv_name" spawnarg on the custom item and the "item_name" spawnarg on the altar. They must match to work.

3. Place a func_static of the item's model on the altar and set spawnarg "hide 1". Have the altar target the func_static and it will appear, giving the illusion it was placed there.

''If you want skull-on-altar to satisfy an objective, additional coding and/or location-detection will need to be added.''

===Extra: Adding a Custom GUI===
Suppose you wanted to extend this example, to make the skull inventory icon pulse with color? You could do this with a custom GUI, explained in [[GUI Scripting: Inventory Icon Example]]. This also provides a inventory script object, that could serve as a template for use in other projects; it may be of more general use that the compass script object. Plus, more about using global and local GUI::Parameters in this context.

[[Category:Editing]]

Carleton Fonts

2026-05-26T16:15:33Z

Geep: /* Improvements to English Carleton 24pt in 2026 */ mention ExportUnicodeFontToDoom3

''By Geep, 2025. The analysis here as of TDM 2.12 and for "english" (including European) unless indicated otherwise.''

== The Carleton Family in a Nutshell ==
Carleton is a squarish print-style serif font. The lower case letters look like smaller versions of the upper case letters, so this font can also be referred to as "Carleton Caps", [[Fonts_Screenshots#Carleton_Caps_only | as in this screenshot]]. Within TDM, there are four members of the Carleton family:
* carleton
* carleton_bold
* carleton_condensed (i.e., more tightly spaced in the horizontal dimension)
* carleton_glow

Base-font carleton is used extensively throughout the main menu system. It may appear by itself, in black, for non-interactive subheadings and descriptions. (In a few places, like the "Downloadable Missions" title, a "headline" style using carleton_bold is deployed.)

Or it may participate in dynamic text highlighting for user interactions, using overlay combinations like:
* carleton and carleton_glow
* carleton_bold and carleton_glow, for titles and headlines
* carleton, carleton_bold and carleton_glow, for certain "new game" buttons

For FMs, there are standard readable sheet and scroll prefabs and sign text decals that use carleton, just by itself. The style of this font makes it a good choices for notices; between title and body, and upper and lower case, there can appear to be four different sizes of "capital" letters.

All these usages predominately involve mid-sized and large text (e.g., GUI textscale 0.24 and up), that draws on the 24pt and 48pt size bitmaps. The "english" form of 24pt and 48pt both offer TDM’s full European glyph set. Glyphs are stylishly done for 48pt and not bad for ASCII characters of 24pt; the accented characters of 24pt are rough-hewn and merely adequate.

While 48pt carleton_bold actually has bold (thickened) glyphs, 24pt carleton_bold glyphs are merely copies of regular 24pt carleton, so not bold.

== File Naming and Content Sharing across the Carleton Family ==
The four members share bitmap naming. For instance, if you examine any of the 4 derived fontimage_24.ref files, you see references like:

shaderName fonts/Carleton_0_24.tga

and it will say "Carleton_..." in all cases, not for instance "Carleton_condensed_...". (As is typically the case in TDM, a shader filetype of .tga actually resolves to .dds, and shaderName is case-insensitive; the actual filenames are all lower-case.)

There is also file content sharing (i.e., duplication). As shown in the tables below, the sharing pattern is more complex, and arguably incoherent. This may reflect errors in distribution, or perhaps some member/size combinations not really being used.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 English Carleton Family DAT Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| fontimage_12.dat || SAME || SAME || SAME || SAME
|-
| fontimage_24.dat || SAME || SAME || unique || SAME
|-
| fontimage_48.dat || SAME || SAME || unique || SAME
|}

The fontimage_24.dat files shown as SAME were updated for 2.15.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 & 2.15 English Carleton Family DDS Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| carleton_0_12.dds || SAME || unique || SAME || unique
|-
| carleton_0_24.dds || '''SAME''' || '''SAME''' || unique || '''SAME''' [was unique before 2.15]
|-
| carleton_1_24.dds || '''SAME''' || '''SAME''' || unique || '''SAME''' [was unique before 2.15]
|-
| carleton_2_24.dds [Added 2.15] || '''SAME''' || '''SAME''' || n/a || '''SAME'''
|-
| carleton_0_48.dds || SAME || unique || SAME || unique
|-
| carleton_1_48.dds || SAME || unique || SAME || unique
|-
| carleton_2_48.dds || SAME || unique || SAME || unique
|-
| carleton_3_48.dds || SAME || unique || SAME || unique
|-
| carleton_4_48.dds || SAME || unique || SAME || unique
|-
| carleton_5_48.dds || SAME || unique || SAME || unique
|-
| carleton_6_48.dds || SAME || unique || SAME || unique
|-
| carleton_7_48.dds || SAME || unique || SAME || unique
|}

The carleton_*_24 DDS files were updated for 2.15 (except for carleton_condensed).

== Bitmap File Sizes across the Carleton Family ==
The english 24pt DDS files '''shown in bold above''' have 512x512 bitmaps. All other files (including those for Russian, not in the table) have the default 256x256 bitmaps. This includes carleton_glow unless bolded. Observe that it is not required that the base & glow have identical bitmap sizes (although that is helpful to allow GIMP layering).

See also [[Refont#Carleton_Family]] for corresponding refont commands.

== Anomalies of Carleton and Carleton Bold 24pt Glyphs ==
As mentioned above, 24pt Carleton Bold is identical to 24pt Carleton; so not really bold. The remaining discussion applies equally to 24pt Carleton and Carleton Bold.

Evidently, the original generation of the 24pt size, into two 256x256 bitmaps "carleton_0_24.dds" and "carleton_1_24.dds", contained only ASCII alphanumeric characters and limited punctuation, with no accented/Latin-1 glyphs. Later, these bitmaps were scaled up to 512x512 bitmaps, to ease drawing in the missing characters by hand. The resulting new characters are coarser than the generated and scaled ASCII characters.

You can see this aspects in the main menu, under Settings/Video/Language, where, in the list of 16 languages, accented letters are thicker.

Also, if viewed in GIMP, the white characters have a faint black border, not seen elsewhere (e.g., in the 48pt bitmaps). This is true of both scaled-up ASCII and drawn Latin-1 characters, though far more prominent in the latter. However, TDM's monochrome, usually black rendering (defined by forecolor in the GUI) obscures the presence of this border effect. The purpose for it is discussed next.

== Carleton When Toggling Choices Within a Submenu ==
Throughout Setting submenus, the Carleton 24pt font is used within option lists. More generally, this presentation style is used for row items within lists.

For example, under Settings/Audio/, there is a row with "Main Menu Music" and a choice of "On" or "Off". This is implemented by a standardized choiceDef.
* On the left, the "Main Menu Music" phrase is carleton, rendered in translucent black (with alpha 0.85) and a textscale of 0.24 (which draws from 24pt).
* On the right, the "On" and "Off" text by default is the same, but slightly smaller at textscale 0.22 (also from 24pt).

When you mouse-hover, the current-value text turns momentarily white with a faint black border. The white is set, not by the GUI, but by the engine's "hoverColor", which is opaque white (1,1,1,1). The black border improves readability against the parchment background. It is due to the "anomolous" black border baked into the font, as discussed above.

''Aside: There is a GUI scripting text attribute "shadow", to draw black drop shadows (offset equally down and right) under font characters. This is not used in the main menu system. Within the engine, "shadow" invokes a "textShadow" boolean, false by default.''

== Improvements to English Carleton 24pt in 2026 ==
''This summarizes what is described in more detail [https://forums.thedarkmod.com/index.php?/topic/23109-improvements-to-carleton-24pt-font here]''

A number of problems needed correcting:
* some missing or bad glyphs
* glyphs lacking their accents
* many "ugly" badly-drawn glyphs
* suboptimal vertical/horizontal placement
* clipping

For TDM 2.15, all 256 of TDM's English/European codepoints, including accents, were implemented,. Ugly glyphs were replaced by fresh ones regenerated from TTF; dev tools were updated to facilitate that (e.g., hirez, bolding, and inPlace options added to [[ExportUnicodeFontToDoom3]]). Placement/spacing, and clipping were generally improved, involving both bitmap and DAT tweaks.

The new system (after a false start) uses three 512x512 bitmaps instead of two.

The previous custom carleton_glow 24pt set of bitmaps with smudged glyphs is no longer used. Instead, a copy of carleton 24pt bitmaps is used for carleton_glow (as well as carleton_bold per previous). Thus, the "glow" relies ''solely'' on the main-menu's simulated "drop shadow" effect (due to overlapped offset GUI defWindows).

Carleton_condensed 24pt font was considered deprecated and not touched by this redo.

== Carleton & Carleton Glow in the Main Menu System ==
This pairing occurs basically everywhere thorough the main menu system. In a typical presentation, against a parchment background, major menu-page-selection keywords are by default rendered in black with no glow. But they will turn white with blood-red glow highlighting when either selected (as if a tab for the current page) or moused-over. This will also play a sound and often show a text hint.

=== Example Implementation ===
TDM uses a number of different "button" (i.e., selectable text) styles, driven by #defines in \tdm_gui01\guis\mainmenu_defs.gui. For example, those of the main menu home page use:
#define MM_NORMAL_FONT "fonts/carleton"
#define MM_GLOW_FONT "fonts/carleton_glow"
#define MM_FONTSCALE 0.33
#define MM_BUTTON_HEIGHT 18

For colors, the text is black initially, with glow highlighting invisible. Upon mouse hover, the text becomes white, and the glow red. RGBA colors are defined for this, in vector and string (with S prefix) forms:

#define NORMAL_COLOR 0,0,0,0.90 // black, not entirely opaque
#define SNORMAL_COLOR "0 0 0 0.90"
#define INVISIBLE 0, 0, 0, 0
#define SINVISIBLE "0 0 0 0"
#define GLOW_WHITE_COLOR 0.98,0.93,0.82,1
#define SGLOW_WHITE_COLOR "0.98 0.93 0.82 1"
#define GLOW_RED_COLOR 0.6,0.1,0.1,0.5 // semi-transparent
#define SGLOW_RED_COLOR "0.6 0.1 0.1 0.5"

To be specific, consider a simplified imaginary main menu "button" we'll call "Simple". (We're avoiding the layout calculations and other complications of a real button.) For our button, there are 3 aligned windowDefs in mainmenu_defs.gui, with these locations:

#define MM_POS_SIMPLE_BUTTON rect 40, 445, 160, MM_BUTTON_HEIGHT * 1.3
#define MM_POS_SIMPLE_BUTTON_GLOW rect 41, 446, 159, MM_BUTTON_HEIGHT * 1.3 - 1
#define MM_POS_SIMPLE_ACTION MM_POS_SIMPLE_BUTTON

The windowDefs positioned by these will also do the following:
* MM_POS_SIMPLE_BUTTON: set the default appearance of the button text.
* MM_POS_SIMPLE_BUTTON_GLOW: set the default appearance of the glow "highlight" text. Note this text is offset down and to the right by one pixel, compared to MM_POS_SIMPLE_BUTTON, to give the glow a "drop shadow" flavor. This is a frequent treatment, though in some cases only the right shift is done.
* MM_POS_SIMPLE_ACTION defines the mouse-over and mouse-selection dynamic behaviors. (Be aware that in some actual cases, this is combined into the first windowDef.)

Then, besides the rects, the other attributes are defined for the two default windowDefs:

#define MM_FONT font MM_NORMAL_FONT forecolor SNORMAL_COLOR textscale MM_FONTSCALE visible 1 textalign 1 // centered text
#define MM_FONT_GLOW font MM_GLOW_FONT forecolor INVISIBLE textscale MM_FONTSCALE visible 1 textalign 1

(This is a simplification; for the main menu, MM_FONT's forecolor is #defined as INVISIBLE, then transitions to SNORMAL_COLOR in 1/2 second.)

Within an overall page layout given by mainmenu_main.gui (but with our button shoved in), we might have nested:

windowDef SimpleTextH
{
rect MM_POS_SIMPLE_BUTTON_GLOW
MM_FONT_GLOW
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleText
{
rect MM_POS_SIMPLE_BUTTON
MM_FONT
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleAction
{
rect MM_POS_SIMPLE_ACTION
visible "gui::showSimple"
float exit;

onMouseEnter
{
set "exit" 0;
transition "SimpleText::forecolor" SNORMAL_COLOR SGLOW_WHITE_COLOR "50" ;
transition "SimpleTextH::forecolor" SINVISIBLE SGLOW_RED_COLOR "50" ;
set "cmd" "play sound/meta/menu/mnu_hover";
}

onMouseExit
{
if ("exit" == 0)
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;
}
}

onAction
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;

set "cmd" "play sound/meta/menu/mnu_select;";
set "cmd" "onSimpleClicked"; // tell engine

// And any additional commands here to switch states, resetTime, etc.
}
}

The "H" (highlighted) windowDef is shown first, to draw behind the main text. onMouseEnter turns the text color from black to white in 50 milliseconds, and the glow from invisible to red. onMouseExit reverses that. onAction, when the button is mouse-selected, does the visual transition as mouse exit, but plays a different sound... and then does whatever "Simple" is supposed to do.

== Carleton in Assets for FMs ==
In the tables below, most content has a textscale above 0.30, so draws from the 48pt size, '''indicated in bold'''. Otherwise, with a textscale of 0.16 to 0.30, from 24pt.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Standard Readable Prefabs.'''
Within \tdm_prefabs01\xdata\prefabs.xd, "gui_page<n>" : "guis/readables/..."
|-
! Prefab !! Title textscale !! Body textscale
|-
| .../books/... none || ||
|-
| .../scrolls/scroll_print_carleton.gui || '''0.40''' || 0.28
|-
| .../sheets/sheet_paper_print_carleton_caps.gui || '''0.40''' || '''0.31'''
|}

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Sign Text.''' Within \sign_text_decals\
|-
! Decal !! Textscale
|-
| sign_text_carleton.gui || '''2'''
|-
| sign_text_carleton_small.gui || '''1'''
|}

== Carleton_condensed ==
As indicated above, Carleton_condensed DDS files are all 256x256.

=== 12pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 12pt carleton_condensed (i.e., by specifying a GUI textscale of 0.15 or less). Instead, use regular carleton, possibly with a slightly smaller textscale.''

Although 12pt carleton_condensed exists, its DAT file and single DDS file are mere placeholders that are identical to those of carleton 12pt.

=== 48pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 48pt carleton_condensed (i.e., by specifying a GUI textscale of above 0.30). Instead, use regular carleton, possibly with a slightly smaller textscale.''

The set of eight DDS files for 48pt carleton_condensed are identical to those for 48pt carleton. However, the DAT file has different content, though the difference is not due to horizontal "condensation".

A one time, Tels drafted a Font Patcher command file for 48pt carleton_condensed, to reduce the width and xSkip of a selected subset of the carleton’s ASCII alphanumeric characters, presumably those most generously spaced to begin with. Evidently this was not finalized and deployed. Instead, inspection of the current 48pt DAT file for carleton_condensed suggests it was based on an early version of carleton, at a time when only some of the accented characters were implemented. (In particular, the DAT lacks re-implemented metrics for chars 128-139 and 145-155.)

=== 24pt Size ===
''The main menu system uses this, but sparingly. Since a "glow" form of carleton_condensed was never developed, only regular non-glow uses are applicable.''

The contents of the DAT file and the set of two DDS files for 48pt carleton_condensed DIFFER from those for 48pt carleton.

For the main menu system, where carleton was used for English-language players, the more-compact carleton_condensed was briefly considered as a method of accommodating European language translations. However, this would require dynamic language switching, and was found to be a hill too far, compared to just reducing Carleton’s textscale value.

The actual limited uses in the main menu systems are seen as you survey the downloadable missions. Specifically, when looking at a candidate mission, the Mission Details page has a Description section, whose body text is carleton_condensed with textscale 0.17. Compared to other similar text section here (that use regular carleton with textscale 0.18), this is slightly smaller and condensed. Also, the Next >> and << Prev buttons for cycling through screenshots have their button captions in this font (with textscale 0.23).

== For More ==
* Character-set coverage of Carleton family is included in the the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

Carleton Fonts

2026-05-26T15:58:48Z

Geep: /* File Naming and Content Sharing across the Carleton Family */

''By Geep, 2025. The analysis here as of TDM 2.12 and for "english" (including European) unless indicated otherwise.''

== The Carleton Family in a Nutshell ==
Carleton is a squarish print-style serif font. The lower case letters look like smaller versions of the upper case letters, so this font can also be referred to as "Carleton Caps", [[Fonts_Screenshots#Carleton_Caps_only | as in this screenshot]]. Within TDM, there are four members of the Carleton family:
* carleton
* carleton_bold
* carleton_condensed (i.e., more tightly spaced in the horizontal dimension)
* carleton_glow

Base-font carleton is used extensively throughout the main menu system. It may appear by itself, in black, for non-interactive subheadings and descriptions. (In a few places, like the "Downloadable Missions" title, a "headline" style using carleton_bold is deployed.)

Or it may participate in dynamic text highlighting for user interactions, using overlay combinations like:
* carleton and carleton_glow
* carleton_bold and carleton_glow, for titles and headlines
* carleton, carleton_bold and carleton_glow, for certain "new game" buttons

For FMs, there are standard readable sheet and scroll prefabs and sign text decals that use carleton, just by itself. The style of this font makes it a good choices for notices; between title and body, and upper and lower case, there can appear to be four different sizes of "capital" letters.

All these usages predominately involve mid-sized and large text (e.g., GUI textscale 0.24 and up), that draws on the 24pt and 48pt size bitmaps. The "english" form of 24pt and 48pt both offer TDM’s full European glyph set. Glyphs are stylishly done for 48pt and not bad for ASCII characters of 24pt; the accented characters of 24pt are rough-hewn and merely adequate.

While 48pt carleton_bold actually has bold (thickened) glyphs, 24pt carleton_bold glyphs are merely copies of regular 24pt carleton, so not bold.

== File Naming and Content Sharing across the Carleton Family ==
The four members share bitmap naming. For instance, if you examine any of the 4 derived fontimage_24.ref files, you see references like:

shaderName fonts/Carleton_0_24.tga

and it will say "Carleton_..." in all cases, not for instance "Carleton_condensed_...". (As is typically the case in TDM, a shader filetype of .tga actually resolves to .dds, and shaderName is case-insensitive; the actual filenames are all lower-case.)

There is also file content sharing (i.e., duplication). As shown in the tables below, the sharing pattern is more complex, and arguably incoherent. This may reflect errors in distribution, or perhaps some member/size combinations not really being used.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 English Carleton Family DAT Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| fontimage_12.dat || SAME || SAME || SAME || SAME
|-
| fontimage_24.dat || SAME || SAME || unique || SAME
|-
| fontimage_48.dat || SAME || SAME || unique || SAME
|}

The fontimage_24.dat files shown as SAME were updated for 2.15.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 & 2.15 English Carleton Family DDS Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| carleton_0_12.dds || SAME || unique || SAME || unique
|-
| carleton_0_24.dds || '''SAME''' || '''SAME''' || unique || '''SAME''' [was unique before 2.15]
|-
| carleton_1_24.dds || '''SAME''' || '''SAME''' || unique || '''SAME''' [was unique before 2.15]
|-
| carleton_2_24.dds [Added 2.15] || '''SAME''' || '''SAME''' || n/a || '''SAME'''
|-
| carleton_0_48.dds || SAME || unique || SAME || unique
|-
| carleton_1_48.dds || SAME || unique || SAME || unique
|-
| carleton_2_48.dds || SAME || unique || SAME || unique
|-
| carleton_3_48.dds || SAME || unique || SAME || unique
|-
| carleton_4_48.dds || SAME || unique || SAME || unique
|-
| carleton_5_48.dds || SAME || unique || SAME || unique
|-
| carleton_6_48.dds || SAME || unique || SAME || unique
|-
| carleton_7_48.dds || SAME || unique || SAME || unique
|}

The carleton_*_24 DDS files were updated for 2.15 (except for carleton_condensed).

== Bitmap File Sizes across the Carleton Family ==
The english 24pt DDS files '''shown in bold above''' have 512x512 bitmaps. All other files (including those for Russian, not in the table) have the default 256x256 bitmaps. This includes carleton_glow unless bolded. Observe that it is not required that the base & glow have identical bitmap sizes (although that is helpful to allow GIMP layering).

See also [[Refont#Carleton_Family]] for corresponding refont commands.

== Anomalies of Carleton and Carleton Bold 24pt Glyphs ==
As mentioned above, 24pt Carleton Bold is identical to 24pt Carleton; so not really bold. The remaining discussion applies equally to 24pt Carleton and Carleton Bold.

Evidently, the original generation of the 24pt size, into two 256x256 bitmaps "carleton_0_24.dds" and "carleton_1_24.dds", contained only ASCII alphanumeric characters and limited punctuation, with no accented/Latin-1 glyphs. Later, these bitmaps were scaled up to 512x512 bitmaps, to ease drawing in the missing characters by hand. The resulting new characters are coarser than the generated and scaled ASCII characters.

You can see this aspects in the main menu, under Settings/Video/Language, where, in the list of 16 languages, accented letters are thicker.

Also, if viewed in GIMP, the white characters have a faint black border, not seen elsewhere (e.g., in the 48pt bitmaps). This is true of both scaled-up ASCII and drawn Latin-1 characters, though far more prominent in the latter. However, TDM's monochrome, usually black rendering (defined by forecolor in the GUI) obscures the presence of this border effect. The purpose for it is discussed next.

== Carleton When Toggling Choices Within a Submenu ==
Throughout Setting submenus, the Carleton 24pt font is used within option lists. More generally, this presentation style is used for row items within lists.

For example, under Settings/Audio/, there is a row with "Main Menu Music" and a choice of "On" or "Off". This is implemented by a standardized choiceDef.
* On the left, the "Main Menu Music" phrase is carleton, rendered in translucent black (with alpha 0.85) and a textscale of 0.24 (which draws from 24pt).
* On the right, the "On" and "Off" text by default is the same, but slightly smaller at textscale 0.22 (also from 24pt).

When you mouse-hover, the current-value text turns momentarily white with a faint black border. The white is set, not by the GUI, but by the engine's "hoverColor", which is opaque white (1,1,1,1). The black border improves readability against the parchment background. It is due to the "anomolous" black border baked into the font, as discussed above.

''Aside: There is a GUI scripting text attribute "shadow", to draw black drop shadows (offset equally down and right) under font characters. This is not used in the main menu system. Within the engine, "shadow" invokes a "textShadow" boolean, false by default.''

== Improvements to English Carleton 24pt in 2026 ==
''This summarizes what is described in more detail [https://forums.thedarkmod.com/index.php?/topic/23109-improvements-to-carleton-24pt-font here]''

A number of problems needed correcting:
* some missing or bad glyphs
* glyphs lacking their accents
* many "ugly" badly-drawn glyphs
* suboptimal vertical/horizontal placement
* clipping

For TDM 2.15, all 256 of TDM's English/European codepoints, including accents, were implemented,. Ugly glyphs were replaced by fresh ones regenerated from TTF; dev tools were updated to facilitate that. Placement/spacing, and clipping were generally improved, involving both bitmap and DAT tweaks.

The new system (after a false start) uses three 512x512 bitmaps instead of two.

The previous custom carleton_glow 24pt set of bitmaps with smudged glyphs is no longer used. Instead, a copy of carleton 24pt bitmaps is used for carleton_glow (as well as carleton_bold per previous). Thus, the "glow" relies ''solely'' on the main-menu's simulated "drop shadow" effect (due to overlapped offset GUI defWindows).

Carleton_condensed 24pt font was considered deprecated and not touched by this redo.

== Carleton & Carleton Glow in the Main Menu System ==
This pairing occurs basically everywhere thorough the main menu system. In a typical presentation, against a parchment background, major menu-page-selection keywords are by default rendered in black with no glow. But they will turn white with blood-red glow highlighting when either selected (as if a tab for the current page) or moused-over. This will also play a sound and often show a text hint.

=== Example Implementation ===
TDM uses a number of different "button" (i.e., selectable text) styles, driven by #defines in \tdm_gui01\guis\mainmenu_defs.gui. For example, those of the main menu home page use:
#define MM_NORMAL_FONT "fonts/carleton"
#define MM_GLOW_FONT "fonts/carleton_glow"
#define MM_FONTSCALE 0.33
#define MM_BUTTON_HEIGHT 18

For colors, the text is black initially, with glow highlighting invisible. Upon mouse hover, the text becomes white, and the glow red. RGBA colors are defined for this, in vector and string (with S prefix) forms:

#define NORMAL_COLOR 0,0,0,0.90 // black, not entirely opaque
#define SNORMAL_COLOR "0 0 0 0.90"
#define INVISIBLE 0, 0, 0, 0
#define SINVISIBLE "0 0 0 0"
#define GLOW_WHITE_COLOR 0.98,0.93,0.82,1
#define SGLOW_WHITE_COLOR "0.98 0.93 0.82 1"
#define GLOW_RED_COLOR 0.6,0.1,0.1,0.5 // semi-transparent
#define SGLOW_RED_COLOR "0.6 0.1 0.1 0.5"

To be specific, consider a simplified imaginary main menu "button" we'll call "Simple". (We're avoiding the layout calculations and other complications of a real button.) For our button, there are 3 aligned windowDefs in mainmenu_defs.gui, with these locations:

#define MM_POS_SIMPLE_BUTTON rect 40, 445, 160, MM_BUTTON_HEIGHT * 1.3
#define MM_POS_SIMPLE_BUTTON_GLOW rect 41, 446, 159, MM_BUTTON_HEIGHT * 1.3 - 1
#define MM_POS_SIMPLE_ACTION MM_POS_SIMPLE_BUTTON

The windowDefs positioned by these will also do the following:
* MM_POS_SIMPLE_BUTTON: set the default appearance of the button text.
* MM_POS_SIMPLE_BUTTON_GLOW: set the default appearance of the glow "highlight" text. Note this text is offset down and to the right by one pixel, compared to MM_POS_SIMPLE_BUTTON, to give the glow a "drop shadow" flavor. This is a frequent treatment, though in some cases only the right shift is done.
* MM_POS_SIMPLE_ACTION defines the mouse-over and mouse-selection dynamic behaviors. (Be aware that in some actual cases, this is combined into the first windowDef.)

Then, besides the rects, the other attributes are defined for the two default windowDefs:

#define MM_FONT font MM_NORMAL_FONT forecolor SNORMAL_COLOR textscale MM_FONTSCALE visible 1 textalign 1 // centered text
#define MM_FONT_GLOW font MM_GLOW_FONT forecolor INVISIBLE textscale MM_FONTSCALE visible 1 textalign 1

(This is a simplification; for the main menu, MM_FONT's forecolor is #defined as INVISIBLE, then transitions to SNORMAL_COLOR in 1/2 second.)

Within an overall page layout given by mainmenu_main.gui (but with our button shoved in), we might have nested:

windowDef SimpleTextH
{
rect MM_POS_SIMPLE_BUTTON_GLOW
MM_FONT_GLOW
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleText
{
rect MM_POS_SIMPLE_BUTTON
MM_FONT
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleAction
{
rect MM_POS_SIMPLE_ACTION
visible "gui::showSimple"
float exit;

onMouseEnter
{
set "exit" 0;
transition "SimpleText::forecolor" SNORMAL_COLOR SGLOW_WHITE_COLOR "50" ;
transition "SimpleTextH::forecolor" SINVISIBLE SGLOW_RED_COLOR "50" ;
set "cmd" "play sound/meta/menu/mnu_hover";
}

onMouseExit
{
if ("exit" == 0)
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;
}
}

onAction
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;

set "cmd" "play sound/meta/menu/mnu_select;";
set "cmd" "onSimpleClicked"; // tell engine

// And any additional commands here to switch states, resetTime, etc.
}
}

The "H" (highlighted) windowDef is shown first, to draw behind the main text. onMouseEnter turns the text color from black to white in 50 milliseconds, and the glow from invisible to red. onMouseExit reverses that. onAction, when the button is mouse-selected, does the visual transition as mouse exit, but plays a different sound... and then does whatever "Simple" is supposed to do.

== Carleton in Assets for FMs ==
In the tables below, most content has a textscale above 0.30, so draws from the 48pt size, '''indicated in bold'''. Otherwise, with a textscale of 0.16 to 0.30, from 24pt.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Standard Readable Prefabs.'''
Within \tdm_prefabs01\xdata\prefabs.xd, "gui_page<n>" : "guis/readables/..."
|-
! Prefab !! Title textscale !! Body textscale
|-
| .../books/... none || ||
|-
| .../scrolls/scroll_print_carleton.gui || '''0.40''' || 0.28
|-
| .../sheets/sheet_paper_print_carleton_caps.gui || '''0.40''' || '''0.31'''
|}

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Sign Text.''' Within \sign_text_decals\
|-
! Decal !! Textscale
|-
| sign_text_carleton.gui || '''2'''
|-
| sign_text_carleton_small.gui || '''1'''
|}

== Carleton_condensed ==
As indicated above, Carleton_condensed DDS files are all 256x256.

=== 12pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 12pt carleton_condensed (i.e., by specifying a GUI textscale of 0.15 or less). Instead, use regular carleton, possibly with a slightly smaller textscale.''

Although 12pt carleton_condensed exists, its DAT file and single DDS file are mere placeholders that are identical to those of carleton 12pt.

=== 48pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 48pt carleton_condensed (i.e., by specifying a GUI textscale of above 0.30). Instead, use regular carleton, possibly with a slightly smaller textscale.''

The set of eight DDS files for 48pt carleton_condensed are identical to those for 48pt carleton. However, the DAT file has different content, though the difference is not due to horizontal "condensation".

A one time, Tels drafted a Font Patcher command file for 48pt carleton_condensed, to reduce the width and xSkip of a selected subset of the carleton’s ASCII alphanumeric characters, presumably those most generously spaced to begin with. Evidently this was not finalized and deployed. Instead, inspection of the current 48pt DAT file for carleton_condensed suggests it was based on an early version of carleton, at a time when only some of the accented characters were implemented. (In particular, the DAT lacks re-implemented metrics for chars 128-139 and 145-155.)

=== 24pt Size ===
''The main menu system uses this, but sparingly. Since a "glow" form of carleton_condensed was never developed, only regular non-glow uses are applicable.''

The contents of the DAT file and the set of two DDS files for 48pt carleton_condensed DIFFER from those for 48pt carleton.

For the main menu system, where carleton was used for English-language players, the more-compact carleton_condensed was briefly considered as a method of accommodating European language translations. However, this would require dynamic language switching, and was found to be a hill too far, compared to just reducing Carleton’s textscale value.

The actual limited uses in the main menu systems are seen as you survey the downloadable missions. Specifically, when looking at a candidate mission, the Mission Details page has a Description section, whose body text is carleton_condensed with textscale 0.17. Compared to other similar text section here (that use regular carleton with textscale 0.18), this is slightly smaller and condensed. Also, the Next >> and << Prev buttons for cycling through screenshots have their button captions in this font (with textscale 0.23).

== For More ==
* Character-set coverage of Carleton family is included in the the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

Carleton Fonts

2026-05-26T15:25:57Z

Geep: Changed tables, added Improvements to English Carleton 24pt in 2026

''By Geep, 2025. The analysis here as of TDM 2.12 and for "english" (including European) unless indicated otherwise.''

== The Carleton Family in a Nutshell ==
Carleton is a squarish print-style serif font. The lower case letters look like smaller versions of the upper case letters, so this font can also be referred to as "Carleton Caps", [[Fonts_Screenshots#Carleton_Caps_only | as in this screenshot]]. Within TDM, there are four members of the Carleton family:
* carleton
* carleton_bold
* carleton_condensed (i.e., more tightly spaced in the horizontal dimension)
* carleton_glow

Base-font carleton is used extensively throughout the main menu system. It may appear by itself, in black, for non-interactive subheadings and descriptions. (In a few places, like the "Downloadable Missions" title, a "headline" style using carleton_bold is deployed.)

Or it may participate in dynamic text highlighting for user interactions, using overlay combinations like:
* carleton and carleton_glow
* carleton_bold and carleton_glow, for titles and headlines
* carleton, carleton_bold and carleton_glow, for certain "new game" buttons

For FMs, there are standard readable sheet and scroll prefabs and sign text decals that use carleton, just by itself. The style of this font makes it a good choices for notices; between title and body, and upper and lower case, there can appear to be four different sizes of "capital" letters.

All these usages predominately involve mid-sized and large text (e.g., GUI textscale 0.24 and up), that draws on the 24pt and 48pt size bitmaps. The "english" form of 24pt and 48pt both offer TDM’s full European glyph set. Glyphs are stylishly done for 48pt and not bad for ASCII characters of 24pt; the accented characters of 24pt are rough-hewn and merely adequate.

While 48pt carleton_bold actually has bold (thickened) glyphs, 24pt carleton_bold glyphs are merely copies of regular 24pt carleton, so not bold.

== File Naming and Content Sharing across the Carleton Family ==
The four members share bitmap naming. For instance, if you examine any of the 4 derived fontimage_24.ref files, you see references like:

shaderName fonts/Carleton_0_24.tga

and it will say "Carleton_..." in all cases, not for instance "Carleton_condensed_...". (As is typically the case in TDM, a shader filetype of .tga actually resolves to .dds, and shaderName is case-insensitive; the actual filenames are all lower-case.)

There is also file content sharing (i.e., duplication). As shown in the tables below, the sharing pattern is more complex, and arguably incoherent. This may reflect errors in distribution, or perhaps some member/size combinations not really being used.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 English Carleton Family DAT Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| fontimage_12.dat || SAME || SAME || SAME || SAME
|-
| fontimage_24.dat || SAME || SAME || unique || SAME
|-
| fontimage_48.dat || SAME || SAME || unique || SAME
|}

The fontimage_24.dat files shown as '''SAME''' were updated for 2.15.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 & 2.15 English Carleton Family DDS Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| carleton_0_12.dds || SAME || unique || SAME || unique
|-
| carleton_0_24.dds || '''SAME''' || '''SAME''' || unique || '''SAME''' [was unique before 2.15]
|-
| carleton_1_24.dds || '''SAME''' || '''SAME''' || unique || '''SAME''' [was unique before 2.15]
|-
| carleton_2_24.dds [Added 2.15] || '''SAME''' || '''SAME''' || n/a || '''SAME'''
|-
| carleton_0_48.dds || SAME || unique || SAME || unique
|-
| carleton_1_48.dds || SAME || unique || SAME || unique
|-
| carleton_2_48.dds || SAME || unique || SAME || unique
|-
| carleton_3_48.dds || SAME || unique || SAME || unique
|-
| carleton_4_48.dds || SAME || unique || SAME || unique
|-
| carleton_5_48.dds || SAME || unique || SAME || unique
|-
| carleton_6_48.dds || SAME || unique || SAME || unique
|-
| carleton_7_48.dds || SAME || unique || SAME || unique
|}

The carleton_*_24 DDS files were updated for 2.15 (except for carleton_condensed).

== Bitmap File Sizes across the Carleton Family ==
The english 24pt DDS files '''shown in bold above''' have 512x512 bitmaps. All other files (including those for Russian, not in the table) have the default 256x256 bitmaps. This includes carleton_glow unless bolded. Observe that it is not required that the base & glow have identical bitmap sizes (although that is helpful to allow GIMP layering).

See also [[Refont#Carleton_Family]] for corresponding refont commands.

== Anomalies of Carleton and Carleton Bold 24pt Glyphs ==
As mentioned above, 24pt Carleton Bold is identical to 24pt Carleton; so not really bold. The remaining discussion applies equally to 24pt Carleton and Carleton Bold.

Evidently, the original generation of the 24pt size, into two 256x256 bitmaps "carleton_0_24.dds" and "carleton_1_24.dds", contained only ASCII alphanumeric characters and limited punctuation, with no accented/Latin-1 glyphs. Later, these bitmaps were scaled up to 512x512 bitmaps, to ease drawing in the missing characters by hand. The resulting new characters are coarser than the generated and scaled ASCII characters.

You can see this aspects in the main menu, under Settings/Video/Language, where, in the list of 16 languages, accented letters are thicker.

Also, if viewed in GIMP, the white characters have a faint black border, not seen elsewhere (e.g., in the 48pt bitmaps). This is true of both scaled-up ASCII and drawn Latin-1 characters, though far more prominent in the latter. However, TDM's monochrome, usually black rendering (defined by forecolor in the GUI) obscures the presence of this border effect. The purpose for it is discussed next.

== Carleton When Toggling Choices Within a Submenu ==
Throughout Setting submenus, the Carleton 24pt font is used within option lists. More generally, this presentation style is used for row items within lists.

For example, under Settings/Audio/, there is a row with "Main Menu Music" and a choice of "On" or "Off". This is implemented by a standardized choiceDef.
* On the left, the "Main Menu Music" phrase is carleton, rendered in translucent black (with alpha 0.85) and a textscale of 0.24 (which draws from 24pt).
* On the right, the "On" and "Off" text by default is the same, but slightly smaller at textscale 0.22 (also from 24pt).

When you mouse-hover, the current-value text turns momentarily white with a faint black border. The white is set, not by the GUI, but by the engine's "hoverColor", which is opaque white (1,1,1,1). The black border improves readability against the parchment background. It is due to the "anomolous" black border baked into the font, as discussed above.

''Aside: There is a GUI scripting text attribute "shadow", to draw black drop shadows (offset equally down and right) under font characters. This is not used in the main menu system. Within the engine, "shadow" invokes a "textShadow" boolean, false by default.''

== Improvements to English Carleton 24pt in 2026 ==
''This summarizes what is described in more detail [https://forums.thedarkmod.com/index.php?/topic/23109-improvements-to-carleton-24pt-font here]''

A number of problems needed correcting:
* some missing or bad glyphs
* glyphs lacking their accents
* many "ugly" badly-drawn glyphs
* suboptimal vertical/horizontal placement
* clipping

For TDM 2.15, all 256 of TDM's English/European codepoints, including accents, were implemented,. Ugly glyphs were replaced by fresh ones regenerated from TTF; dev tools were updated to facilitate that. Placement/spacing, and clipping were generally improved, involving both bitmap and DAT tweaks.

The new system (after a false start) uses three 512x512 bitmaps instead of two.

The previous custom carleton_glow 24pt set of bitmaps with smudged glyphs is no longer used. Instead, a copy of carleton 24pt bitmaps is used for carleton_glow (as well as carleton_bold per previous). Thus, the "glow" relies ''solely'' on the main-menu's simulated "drop shadow" effect (due to overlapped offset GUI defWindows).

Carleton_condensed 24pt font was considered deprecated and not touched by this redo.

== Carleton & Carleton Glow in the Main Menu System ==
This pairing occurs basically everywhere thorough the main menu system. In a typical presentation, against a parchment background, major menu-page-selection keywords are by default rendered in black with no glow. But they will turn white with blood-red glow highlighting when either selected (as if a tab for the current page) or moused-over. This will also play a sound and often show a text hint.

=== Example Implementation ===
TDM uses a number of different "button" (i.e., selectable text) styles, driven by #defines in \tdm_gui01\guis\mainmenu_defs.gui. For example, those of the main menu home page use:
#define MM_NORMAL_FONT "fonts/carleton"
#define MM_GLOW_FONT "fonts/carleton_glow"
#define MM_FONTSCALE 0.33
#define MM_BUTTON_HEIGHT 18

For colors, the text is black initially, with glow highlighting invisible. Upon mouse hover, the text becomes white, and the glow red. RGBA colors are defined for this, in vector and string (with S prefix) forms:

#define NORMAL_COLOR 0,0,0,0.90 // black, not entirely opaque
#define SNORMAL_COLOR "0 0 0 0.90"
#define INVISIBLE 0, 0, 0, 0
#define SINVISIBLE "0 0 0 0"
#define GLOW_WHITE_COLOR 0.98,0.93,0.82,1
#define SGLOW_WHITE_COLOR "0.98 0.93 0.82 1"
#define GLOW_RED_COLOR 0.6,0.1,0.1,0.5 // semi-transparent
#define SGLOW_RED_COLOR "0.6 0.1 0.1 0.5"

To be specific, consider a simplified imaginary main menu "button" we'll call "Simple". (We're avoiding the layout calculations and other complications of a real button.) For our button, there are 3 aligned windowDefs in mainmenu_defs.gui, with these locations:

#define MM_POS_SIMPLE_BUTTON rect 40, 445, 160, MM_BUTTON_HEIGHT * 1.3
#define MM_POS_SIMPLE_BUTTON_GLOW rect 41, 446, 159, MM_BUTTON_HEIGHT * 1.3 - 1
#define MM_POS_SIMPLE_ACTION MM_POS_SIMPLE_BUTTON

The windowDefs positioned by these will also do the following:
* MM_POS_SIMPLE_BUTTON: set the default appearance of the button text.
* MM_POS_SIMPLE_BUTTON_GLOW: set the default appearance of the glow "highlight" text. Note this text is offset down and to the right by one pixel, compared to MM_POS_SIMPLE_BUTTON, to give the glow a "drop shadow" flavor. This is a frequent treatment, though in some cases only the right shift is done.
* MM_POS_SIMPLE_ACTION defines the mouse-over and mouse-selection dynamic behaviors. (Be aware that in some actual cases, this is combined into the first windowDef.)

Then, besides the rects, the other attributes are defined for the two default windowDefs:

#define MM_FONT font MM_NORMAL_FONT forecolor SNORMAL_COLOR textscale MM_FONTSCALE visible 1 textalign 1 // centered text
#define MM_FONT_GLOW font MM_GLOW_FONT forecolor INVISIBLE textscale MM_FONTSCALE visible 1 textalign 1

(This is a simplification; for the main menu, MM_FONT's forecolor is #defined as INVISIBLE, then transitions to SNORMAL_COLOR in 1/2 second.)

Within an overall page layout given by mainmenu_main.gui (but with our button shoved in), we might have nested:

windowDef SimpleTextH
{
rect MM_POS_SIMPLE_BUTTON_GLOW
MM_FONT_GLOW
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleText
{
rect MM_POS_SIMPLE_BUTTON
MM_FONT
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleAction
{
rect MM_POS_SIMPLE_ACTION
visible "gui::showSimple"
float exit;

onMouseEnter
{
set "exit" 0;
transition "SimpleText::forecolor" SNORMAL_COLOR SGLOW_WHITE_COLOR "50" ;
transition "SimpleTextH::forecolor" SINVISIBLE SGLOW_RED_COLOR "50" ;
set "cmd" "play sound/meta/menu/mnu_hover";
}

onMouseExit
{
if ("exit" == 0)
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;
}
}

onAction
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;

set "cmd" "play sound/meta/menu/mnu_select;";
set "cmd" "onSimpleClicked"; // tell engine

// And any additional commands here to switch states, resetTime, etc.
}
}

The "H" (highlighted) windowDef is shown first, to draw behind the main text. onMouseEnter turns the text color from black to white in 50 milliseconds, and the glow from invisible to red. onMouseExit reverses that. onAction, when the button is mouse-selected, does the visual transition as mouse exit, but plays a different sound... and then does whatever "Simple" is supposed to do.

== Carleton in Assets for FMs ==
In the tables below, most content has a textscale above 0.30, so draws from the 48pt size, '''indicated in bold'''. Otherwise, with a textscale of 0.16 to 0.30, from 24pt.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Standard Readable Prefabs.'''
Within \tdm_prefabs01\xdata\prefabs.xd, "gui_page<n>" : "guis/readables/..."
|-
! Prefab !! Title textscale !! Body textscale
|-
| .../books/... none || ||
|-
| .../scrolls/scroll_print_carleton.gui || '''0.40''' || 0.28
|-
| .../sheets/sheet_paper_print_carleton_caps.gui || '''0.40''' || '''0.31'''
|}

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Sign Text.''' Within \sign_text_decals\
|-
! Decal !! Textscale
|-
| sign_text_carleton.gui || '''2'''
|-
| sign_text_carleton_small.gui || '''1'''
|}

== Carleton_condensed ==
As indicated above, Carleton_condensed DDS files are all 256x256.

=== 12pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 12pt carleton_condensed (i.e., by specifying a GUI textscale of 0.15 or less). Instead, use regular carleton, possibly with a slightly smaller textscale.''

Although 12pt carleton_condensed exists, its DAT file and single DDS file are mere placeholders that are identical to those of carleton 12pt.

=== 48pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 48pt carleton_condensed (i.e., by specifying a GUI textscale of above 0.30). Instead, use regular carleton, possibly with a slightly smaller textscale.''

The set of eight DDS files for 48pt carleton_condensed are identical to those for 48pt carleton. However, the DAT file has different content, though the difference is not due to horizontal "condensation".

A one time, Tels drafted a Font Patcher command file for 48pt carleton_condensed, to reduce the width and xSkip of a selected subset of the carleton’s ASCII alphanumeric characters, presumably those most generously spaced to begin with. Evidently this was not finalized and deployed. Instead, inspection of the current 48pt DAT file for carleton_condensed suggests it was based on an early version of carleton, at a time when only some of the accented characters were implemented. (In particular, the DAT lacks re-implemented metrics for chars 128-139 and 145-155.)

=== 24pt Size ===
''The main menu system uses this, but sparingly. Since a "glow" form of carleton_condensed was never developed, only regular non-glow uses are applicable.''

The contents of the DAT file and the set of two DDS files for 48pt carleton_condensed DIFFER from those for 48pt carleton.

For the main menu system, where carleton was used for English-language players, the more-compact carleton_condensed was briefly considered as a method of accommodating European language translations. However, this would require dynamic language switching, and was found to be a hill too far, compared to just reducing Carleton’s textscale value.

The actual limited uses in the main menu systems are seen as you survey the downloadable missions. Specifically, when looking at a candidate mission, the Mission Details page has a Description section, whose body text is carleton_condensed with textscale 0.17. Compared to other similar text section here (that use regular carleton with textscale 0.18), this is slightly smaller and condensed. Also, the Next >> and << Prev buttons for cycling through screenshots have their button captions in this font (with textscale 0.23).

== For More ==
* Character-set coverage of Carleton family is included in the the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

The Parts and Whole: DR Layers

2026-05-23T21:11:43Z

Geep: /* See Also */ add link to Layers

''By Geep 2022''
==Introduction==
In a hurry? See [https://www.darkradiant.net/userguide/#_using_layers Using Layers, in the DR User Manual].

In what follows, LMB and RMB are abbreviations for left and right mouse buttons.

A "Layer" is any arbitrary collection of map objects; you define it by giving it a name (in the Layers viewer) and assigning each object to it (from the RMB menu). Once established, a Layer’s objects can be quickly made visible or not, or selected/deselected. An object can be assigned to multiple Layers. Unassigned objects are considered to be in the "Default" Layer. Any Layer can be set as the current "Active Layer", to which newly-created objects are automatically assigned.

Unlike Filters, the use of Layers requires active organizing by you, but provides powerful itemized control. Layers, once created, can persist throughout your project, available to use over and over again. Layers only affect DR, not your FM. Their data is stored in the map/<FM>.darkradiant file.

==Typical Uses==
A Layer can be defined based upon any arbitrary criteria (e.g., location, machine parts, difficulty level, and so on). Thus, a Layer is not necessarily a "layer" in a spatial sense, although it can be used in that way; for example, to create a separate Layer for each floor of a mansion.

One good use of a Layer is to hide geometric objects that are particularly "busy", with a lot of wireframe lines that can obscure other objects in orthogonal views. Some examples:
* Fences and gates with brush bars
* Stairs
* Ground patches

Another use is with complicated ensembles, like a machine with many static and moving parts. This is as an alternative - or even supplement - to putting the parts in an anonymous DR Group.

Layer objects can be anything you can select in your map, including path corners, triggers, AI, visportals and so on. But consider: the visibility of some of these may be adequately managed by Filters alone.

While an object can be assigned to multiple Layers, you can make it your policy to just assign each object to a single layer, if you wish.

==Seeing Layers – the Layers Viewer==
You can bring up the "Layers" viewer by either:
* the top menu’s View/Layers
* keyboard shortcut Ctrl+L

Once open, you’ll see the list of defined layers (only “Default” for a new project), where each row has the following items left to right:
* A button (with tooltip "Toggle layer visibility") that show one of 4 states:
** Blue with checkmark icon = this Layer is currently visible
** Blue with star icon = this Layer is currently visible, and "active", i.e., newly created (but not cloned) objects will be automatically assigned to it.
** Gray with no icon = this Layer is currently hidden
** Gray with star icon = this Layer is currently hidden, but will become the active Layer when "Show all" occurs.
* A slim color swatch. This is red for all Layers that the current selection(s) belong to; otherwise gray. Tooltip: "Indicates whether anything among the current selection is part of this layer".
* The name field, read-only. With tooltip: "Click to select all in layer, hold SHIFT to deselect, hold CTRL to set as active layer."
* A button with a pencil icon (tootip: "Rename this layer", to make the name field editable, except for "Default".
* A button with a red X icon (tooltip: "Delete this layer"), except for "Default". This just deletes the layer, not the objects. Objects that were only assigned to that deleted Layer will be reassigned to "Default".

At the bottom are 3 large buttons: "New" (with a plus sign), "Show all", and "Hide all".

==Visibility of Objects in a Layer==
Hiding an object by either a Filter or View’s Hide/Show will take priority over its visibility due to Layers.
An object can be a member of multiple Layers. Assuming it’s not hidden by Filter or Hide/Show, then if any of its Layers are visible, it is too.

==Selecting All Objects in a Layer==
As just indicated, you can LMB on a Layer’s name field to select all its objects (or Shift+LMB to deselect). Alternatively, you can "Hide all" Layers, show the Layer of interest, then Edit/Invert selection (keyboard shortcut "I").

==Thinking about Naming==
Before you start creating Layers, think a little about what naming convention you want to use. In the Layer viewer, the Layers will always be shown in alphabetical order, and that may be a consideration. Don’t obsess about this; you can always evolve names later. It is seldom useful to have the word "Layer" as part of a name.

==Creating a Layer==
There are two ways to do this:
* In the Layers viewer, hit "New"
* In a map orthogonal view, RMB and "Create Layer…". (Any map object selected before doing this makes no difference.)

Either will bring up a dialog box to enter the Layer name. Subsequently, in the Layers viewer, the new row will appear in alphabetical order.

==Managing Layer Assignments of Existing Objects==
You can perform actions here with or without the Layers viewer open.
With one or more map objects selected, in the orthogonal view, use RMB. There are 3 menu items
* "Add to Layer >". Adds the object(s) to a specified layer, without affecting any of its other Layer assignments. So, if an object is already in "Default" and you assign it "Ground Floor", it will then be in both Layers.
* "Move to Layer >". Adds the object(s) to a specified layer, and removes any of its assignments to other Layers (except for the one newly specified). So caution: any objects that previously were in multiple Layers are now not… if this is not what you want, take further action.
* "Remove from Layer >". Removes the object(s) from a specified layer, without affecting any of its other Layer assignments.

For each of these, further mouse navigation will show the current layer names in a sub-menu. Choose one with LMB.

==Auto-Assigning New Objects using the Active Layer==
When a new map object is created by copying (aka cloning) another object (e.g., with keyboard Space), it automatically gets the source object’s Layer assignment(s).

If instead, a map object is created afresh, it is assigned to the current "active" (i.e., starred) Layer, which is usually "Default", but not always. As discussed next, you can manipulate the star, to speed up assignment of multiple new objects to a particular layer.

==Managing the Active (Starred) Layer==
In the Layers viewer, usually, the "Default" layer has the star, so that newly created map objects (except when copied) are auto-assigned to that layer. You can move the star to a different layer. Quickest way:

Ctrl+LMB on the name field you want to use for auto-assignment. The left button becomes starred.
Another easy way is by hiding all Layers except the one you want active:
# Press “Hide all”. Then all the layer row left buttons will be grayed out. All will be iconless, except "Default" will be starred.
# Hit the leftmost button in the row you want to use for auto-assignment. This Layer becomes visible, and its button will turn blue + starred.
# If you wish, make other rows individually visible, or hit “Show all”. The row starred in (2) remains starred.

Choice of Active Layer is somewhat temporary, in that, if you hide it (either individually or by using "Hide all"), the star always reverts back to "Default". However, the setting will persist across closing and opening the Layers viewer.

==Custom DR Scripting of Layers==
If you need special functionality, DR offers Python scripting, and in particular for Layers exposes a GlobalLayerManager (including LayerVisitor) API with about 2 dozen function calls. See [https://wiki.thedarkmod.com/index.php?title=DarkRadiant_Script_Reference the DarkRadiant Script Reference].

==See Also==
* [[Layers]], for another take on this topic.
* [[The Parts and Whole: Overview]]

{{Editing}}

Layers

2026-05-23T21:09:57Z

Geep: /* See Also */ section added with link to DR Layers]

== Overview ==
[[Image:LayerInspector.jpg|thumb|368px|right|The layer inspector]]
The idea of layers to organize and simplify the users experience in editing media is not a new one. Most image editing software like Photoshop or The Gimp have this feature as well as several 3D modeling/mapping programs, including Dark Radiant, of course. If you are new to the concept of layers, just imagine them as a convenient way to hide elements that are currently in the way.
Please note that layers are only a tool to organize your map, they have no effect in the game.

[[Image:Layers_enabled.jpg|368px|thumb|right|Without layers, working in this cluttered space would be a nightmare...]]
== The Layer Inspector ==
To use Dark Radiant's layer feature, open the layer inspector with the default shortcut {{Key|Ctrl+L}} or via the View->Layers menu entry. If you haven't tinkered with layers yet you should see a list with exactly one entry called ''Default'' (unlike in the screenshot to the right). This is the layer that Dark Radiant automatically creates for you when you begin a new map and that every element belongs to unless you reassign it. It is in every map and can not be removed.

In the layer inspector window you can do the following things:
* By clicking on the checkbox to the left of the layer name you can show/hide a layer respectively it's elements
* Clicking the layer name itself will select/deselect all members of that layer.
* The two buttons to the right of the layer name allow you to change it's name and to delete a layer (in that order). If you delete a layer, it's elements will not be removed from the map, but assigned to the Default layer instead.
* Click on ''New'' to create a new layer. You'll be prompted to give it a unique and - preferably - meaningful name.

[[Image:Layers_disabled.jpg|368px|thumb|right|...but with most of the layers hidden from view everything becomes clear again.]]
== How to Assign Elements to Layers ==
Select one or more elements and then right click anywhere in the orthogonal view. At the bottom of the context menu you should see the following items:
* '''Create Layer...''': Same as ''New'' in the layer inspector.
* '''Add to Layer...''': If you add something to a layer, it will become a member of this layer but also remains in the layers it already belongs to.
* '''Move to Layer...''': Same as above, but the element will exclusively be a member of the newly assigned layer.
* '''Remove from Layer...''': Removes an element from a layer. Note that the list shows all layers, not only those that the selected element is a member of.

== Alternatives ==
There are no real alternatives to layers but three very convenient companions that you may use alongside:
* Select anything you don't want to see and press {{Key|H}} to hide it from view. Press {{Key|Shift+H}} to show it again. If you hide a selection then all the elements you hid previously will remain invisible.
* With [[Defining custom Filters in DarkRadiant|filters]] you can hide specific kinds of entities or textures by using [http://en.wikipedia.org/wiki/Regex regular expressions].
{{editing}}{{darkradiant}}
* With "Selection Focus" you can select some things, go into "Selection Focus" mode (Default key Ctrl-F, if you want to modify the key, it's named "ToggleSelectionFocus") and then you can modify those things without being able to select and modify surrounding elements in the map, but the surroundings are still visible when "Selection focus" is active, while with filters and layers other things get hidden in order to focus on specific things.

== See Also ==
For another take on layers, see [[The_Parts_and_Whole:_DR_Layers]].

I18N - Charset

2026-05-11T19:14:12Z

Geep: /* Coverage Expansion & Remaining Limitations */

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of either the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

or, more recently, the Windows C++ utility program '''gen_lang_plus'''. [[Gen_Lang_Programs]] has details of these.

This process ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6.

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints, and included in TDM 2.14.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

I18N - Charset

2026-05-11T19:08:28Z

Geep: /* all.lang */ Include gen_lang_plus

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of either the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

or, more recently, the Windows C++ utility program '''gen_lang_plus'''. [[Gen_Lang_Programs]] has details of these.

This process ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6.

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

I18N - Charset

2026-05-11T17:48:09Z

Geep: /* Coverage Expansion & Remaining Limitations */ Update Mason 48pt, Carleton 24pt

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

This ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6.

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14.

In 2025, the Russian Mason 48pt font was improved and extended to cover all TDM Russian codepoints.

In 2026, English/European Carleton 24pt, widely used in the main menu and also some readables, was improved to:
* extend coverage to all codepoints
* replace sloppy hand-drawn Latin-1 glyphs with fresh glyphs, most of them generated from TTF then edge-darkened
* for simplicity, re-implement the red "glow" effect as if a drop-shadow.

Testing of this is planned with TDM 2.15 betas.

Stone 48pt improvements are under consideration for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

Carleton Fonts

2026-05-04T17:55:46Z

Geep: /* Carleton When Toggling Choices Within a Submenu */

''By Geep, 2025. The analysis here as of TDM 2.12 and for "english" (including European) unless indicated otherwise.''

== The Carleton Family in a Nutshell ==
Carleton is a squarish print-style serif font. The lower case letters look like smaller versions of the upper case letters, so this font can also be referred to as "Carleton Caps", [[Fonts_Screenshots#Carleton_Caps_only | as in this screenshot]]. Within TDM, there are four members of the Carleton family:
* carleton
* carleton_bold
* carleton_condensed (i.e., more tightly spaced in the horizontal dimension)
* carleton_glow

Base-font carleton is used extensively throughout the main menu system. It may appear by itself, in black, for non-interactive subheadings and descriptions. (In a few places, like the "Downloadable Missions" title, a "headline" style using carleton_bold is deployed.)

Or it may participate in dynamic text highlighting for user interactions, using overlay combinations like:
* carleton and carleton_glow
* carleton_bold and carleton_glow, for titles and headlines
* carleton, carleton_bold and carleton_glow, for certain "new game" buttons

For FMs, there are standard readable sheet and scroll prefabs and sign text decals that use carleton, just by itself. The style of this font makes it a good choices for notices; between title and body, and upper and lower case, there can appear to be four different sizes of "capital" letters.

All these usages predominately involve mid-sized and large text (e.g., GUI textscale 0.24 and up), that draws on the 24pt and 48pt size bitmaps. The "english" form of 24pt and 48pt both offer TDM’s full European glyph set. Glyphs are stylishly done for 48pt and not bad for ASCII characters of 24pt; the accented characters of 24pt are rough-hewn and merely adequate.

While 48pt carleton_bold actually has bold (thickened) glyphs, 24pt carleton_bold glyphs are merely copies of regular 24pt carleton, so not bold.

== File Naming and Content Sharing across the Carleton Family ==
The four members share bitmap naming. For instance, if you examine any of the 4 derived fontimage_24.ref files, you see references like:

shaderName fonts/Carleton_0_24.tga

and it will say "Carleton_..." in all cases, not for instance "Carleton_condensed_...". (As is typically the case in TDM, a shader filetype of .tga actually resolves to .dds, and shaderName is case-insensitive; the actual filenames are all lower-case.)

There is also file content sharing (i.e., duplication). As shown in the tables below, the sharing pattern is more complex, and arguably incoherent. This may reflect errors in distribution, or perhaps some member/size combinations not really being used.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 English Carleton Family DAT Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| fontimage_12.dat || SAME || SAME || SAME || SAME
|-
| fontimage_24.dat || SAME || SAME || unique || SAME
|-
| fontimage_48.dat || SAME || SAME || unique || SAME
|}

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 English Carleton Family DDS Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| carleton_0_12.dds || SAME || unique || SAME || unique
|-
| carleton_0_24.dds || '''SAME''' || '''SAME''' || unique || unique
|-
| carleton_1_24.dds || '''SAME''' || '''SAME''' || unique || unique
|-
| carleton_0_48.dds || SAME || unique || SAME || unique
|-
| carleton_1_48.dds || SAME || unique || SAME || unique
|-
| carleton_2_48.dds || SAME || unique || SAME || unique
|-
| carleton_3_48.dds || SAME || unique || SAME || unique
|-
| carleton_4_48.dds || SAME || unique || SAME || unique
|-
| carleton_5_48.dds || SAME || unique || SAME || unique
|-
| carleton_6_48.dds || SAME || unique || SAME || unique
|-
| carleton_7_48.dds || SAME || unique || SAME || unique
|}

== Bitmap File Sizes across the Carleton Family ==
The english 24pt DDS files '''shown in bold above''' have 512x512 bitmaps. All other files (including those for Russian, not in the table) have the default 256x256 bitmaps. This includes carleton_glow. Observe that it is not required that the base & glow have identical bitmap sizes (although that is helpful to allow GIMP layering).

See also [[Refont#Carleton_Family]] for corresponding refont commands.

== Anomalies of Carleton and Carleton Bold 24pt Glyphs ==
As mentioned above, 24pt Carleton Bold is identical to 24pt Carleton; so not really bold. The remaining discussion applies equally to 24pt Carleton and Carleton Bold.

Evidently, the original generation of the 24pt size, into two 256x256 bitmaps "carleton_0_24.dds" and "carleton_1_24.dds", contained only ASCII alphanumeric characters and limited punctuation, with no accented/Latin-1 glyphs. Later, these bitmaps were scaled up to 512x512 bitmaps, to ease drawing in the missing characters by hand. The resulting new characters are coarser than the generated and scaled ASCII characters.

You can see this aspects in the main menu, under Settings/Video/Language, where, in the list of 16 languages, accented letters are thicker.

Also, if viewed in GIMP, the white characters have a faint black border, not seen elsewhere (e.g., in the 48pt bitmaps). This is true of both scaled-up ASCII and drawn Latin-1 characters, though far more prominent in the latter. However, TDM's monochrome, usually black rendering (defined by forecolor in the GUI) obscures the presence of this border effect. The purpose for it is discussed next.

== Carleton When Toggling Choices Within a Submenu ==
Throughout Setting submenus, the Carleton 24pt font is used within option lists. More generally, this presentation style is used for row items within lists.

For example, under Settings/Audio/, there is a row with "Main Menu Music" and a choice of "On" or "Off". This is implemented by a standardized choiceDef.
* On the left, the "Main Menu Music" phrase is carleton, rendered in translucent black (with alpha 0.85) and a textscale of 0.24 (which draws from 24pt).
* On the right, the "On" and "Off" text by default is the same, but slightly smaller at textscale 0.22 (also from 24pt).

When you mouse-hover, the current-value text turns momentarily white with a faint black border. The white is set, not by the GUI, but by the engine's "hoverColor", which is opaque white (1,1,1,1). The black border improves readability against the parchment background. It is due to the "anomolous" black border baked into the font, as discussed above.

''Aside: There is a GUI scripting text attribute "shadow", to draw black drop shadows (offset equally down and right) under font characters. This is not used in the main menu system. Within the engine, "shadow" invokes a "textShadow" boolean, false by default.''

== Carleton & Carleton Glow in the Main Menu System ==
This pairing occurs basically everywhere thorough the main menu system. In a typical presentation, against a parchment background, major menu-page-selection keywords are by default rendered in black with no glow. But they will turn white with blood-red glow highlighting when either selected (as if a tab for the current page) or moused-over. This will also play a sound and often show a text hint.

=== Example Implementation ===
TDM uses a number of different "button" (i.e., selectable text) styles, driven by #defines in \tdm_gui01\guis\mainmenu_defs.gui. For example, those of the main menu home page use:
#define MM_NORMAL_FONT "fonts/carleton"
#define MM_GLOW_FONT "fonts/carleton_glow"
#define MM_FONTSCALE 0.33
#define MM_BUTTON_HEIGHT 18

For colors, the text is black initially, with glow highlighting invisible. Upon mouse hover, the text becomes white, and the glow red. RGBA colors are defined for this, in vector and string (with S prefix) forms:

#define NORMAL_COLOR 0,0,0,0.90 // black, not entirely opaque
#define SNORMAL_COLOR "0 0 0 0.90"
#define INVISIBLE 0, 0, 0, 0
#define SINVISIBLE "0 0 0 0"
#define GLOW_WHITE_COLOR 0.98,0.93,0.82,1
#define SGLOW_WHITE_COLOR "0.98 0.93 0.82 1"
#define GLOW_RED_COLOR 0.6,0.1,0.1,0.5 // semi-transparent
#define SGLOW_RED_COLOR "0.6 0.1 0.1 0.5"

To be specific, consider a simplified imaginary main menu "button" we'll call "Simple". (We're avoiding the layout calculations and other complications of a real button.) For our button, there are 3 aligned windowDefs in mainmenu_defs.gui, with these locations:

#define MM_POS_SIMPLE_BUTTON rect 40, 445, 160, MM_BUTTON_HEIGHT * 1.3
#define MM_POS_SIMPLE_BUTTON_GLOW rect 41, 446, 159, MM_BUTTON_HEIGHT * 1.3 - 1
#define MM_POS_SIMPLE_ACTION MM_POS_SIMPLE_BUTTON

The windowDefs positioned by these will also do the following:
* MM_POS_SIMPLE_BUTTON: set the default appearance of the button text.
* MM_POS_SIMPLE_BUTTON_GLOW: set the default appearance of the glow "highlight" text. Note this text is offset down and to the right by one pixel, compared to MM_POS_SIMPLE_BUTTON, to give the glow a "drop shadow" flavor. This is a frequent treatment, though in some cases only the right shift is done.
* MM_POS_SIMPLE_ACTION defines the mouse-over and mouse-selection dynamic behaviors. (Be aware that in some actual cases, this is combined into the first windowDef.)

Then, besides the rects, the other attributes are defined for the two default windowDefs:

#define MM_FONT font MM_NORMAL_FONT forecolor SNORMAL_COLOR textscale MM_FONTSCALE visible 1 textalign 1 // centered text
#define MM_FONT_GLOW font MM_GLOW_FONT forecolor INVISIBLE textscale MM_FONTSCALE visible 1 textalign 1

(This is a simplification; for the main menu, MM_FONT's forecolor is #defined as INVISIBLE, then transitions to SNORMAL_COLOR in 1/2 second.)

Within an overall page layout given by mainmenu_main.gui (but with our button shoved in), we might have nested:

windowDef SimpleTextH
{
rect MM_POS_SIMPLE_BUTTON_GLOW
MM_FONT_GLOW
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleText
{
rect MM_POS_SIMPLE_BUTTON
MM_FONT
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleAction
{
rect MM_POS_SIMPLE_ACTION
visible "gui::showSimple"
float exit;

onMouseEnter
{
set "exit" 0;
transition "SimpleText::forecolor" SNORMAL_COLOR SGLOW_WHITE_COLOR "50" ;
transition "SimpleTextH::forecolor" SINVISIBLE SGLOW_RED_COLOR "50" ;
set "cmd" "play sound/meta/menu/mnu_hover";
}

onMouseExit
{
if ("exit" == 0)
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;
}
}

onAction
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;

set "cmd" "play sound/meta/menu/mnu_select;";
set "cmd" "onSimpleClicked"; // tell engine

// And any additional commands here to switch states, resetTime, etc.
}
}

The "H" (highlighted) windowDef is shown first, to draw behind the main text. onMouseEnter turns the text color from black to white in 50 milliseconds, and the glow from invisible to red. onMouseExit reverses that. onAction, when the button is mouse-selected, does the visual transition as mouse exit, but plays a different sound... and then does whatever "Simple" is supposed to do.

== Carleton in Assets for FMs ==
In the tables below, most content has a textscale above 0.30, so draws from the 48pt size, '''indicated in bold'''. Otherwise, with a textscale of 0.16 to 0.30, from 24pt.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Standard Readable Prefabs.'''
Within \tdm_prefabs01\xdata\prefabs.xd, "gui_page<n>" : "guis/readables/..."
|-
! Prefab !! Title textscale !! Body textscale
|-
| .../books/... none || ||
|-
| .../scrolls/scroll_print_carleton.gui || '''0.40''' || 0.28
|-
| .../sheets/sheet_paper_print_carleton_caps.gui || '''0.40''' || '''0.31'''
|}

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Sign Text.''' Within \sign_text_decals\
|-
! Decal !! Textscale
|-
| sign_text_carleton.gui || '''2'''
|-
| sign_text_carleton_small.gui || '''1'''
|}

== Carleton_condensed ==
As indicated above, Carleton_condensed DDS files are all 256x256.

=== 12pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 12pt carleton_condensed (i.e., by specifying a GUI textscale of 0.15 or less). Instead, use regular carleton, possibly with a slightly smaller textscale.''

Although 12pt carleton_condensed exists, its DAT file and single DDS file are mere placeholders that are identical to those of carleton 12pt.

=== 48pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 48pt carleton_condensed (i.e., by specifying a GUI textscale of above 0.30). Instead, use regular carleton, possibly with a slightly smaller textscale.''

The set of eight DDS files for 48pt carleton_condensed are identical to those for 48pt carleton. However, the DAT file has different content, though the difference is not due to horizontal "condensation".

A one time, Tels drafted a Font Patcher command file for 48pt carleton_condensed, to reduce the width and xSkip of a selected subset of the carleton’s ASCII alphanumeric characters, presumably those most generously spaced to begin with. Evidently this was not finalized and deployed. Instead, inspection of the current 48pt DAT file for carleton_condensed suggests it was based on an early version of carleton, at a time when only some of the accented characters were implemented. (In particular, the DAT lacks re-implemented metrics for chars 128-139 and 145-155.)

=== 24pt Size ===
''The main menu system uses this, but sparingly. Since a "glow" form of carleton_condensed was never developed, only regular non-glow uses are applicable.''

The contents of the DAT file and the set of two DDS files for 48pt carleton_condensed DIFFER from those for 48pt carleton.

For the main menu system, where carleton was used for English-language players, the more-compact carleton_condensed was briefly considered as a method of accommodating European language translations. However, this would require dynamic language switching, and was found to be a hill too far, compared to just reducing Carleton’s textscale value.

The actual limited uses in the main menu systems are seen as you survey the downloadable missions. Specifically, when looking at a candidate mission, the Mission Details page has a Description section, whose body text is carleton_condensed with textscale 0.17. Compared to other similar text section here (that use regular carleton with textscale 0.18), this is slightly smaller and condensed. Also, the Next >> and << Prev buttons for cycling through screenshots have their button captions in this font (with textscale 0.23).

== For More ==
* Character-set coverage of Carleton family is included in the the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

GUI Scripting: Properties in Common

2026-05-04T17:43:52Z

Geep: /* shadow bool */ Indicate it may take an int

''This page is part of a series. See [[GUI Scripting Language]] for overview.''
==Introduction==
Here is a catalogue of Properties common to windowDefs and all other members of the "guiDef" family. (Each member's additional task-related Properties are detailed individually elsewhere.) The catalogue is arranged by:

1) Frequency of use in TDM (widely; seldom; debug; unlikely to be useful)

2) General purpose

* rectangle size, location, and appearance
* text and font attributes
* cursor attributes
* timer and events
3) Alphabetically

A Property has a predefined name, type (Boolean, float, vec2, vec4, string) and default value. Properties appear in a <Property List>, by convention at the start of a guiDef's body, after the "{". Routinely, one Property is listed per line. Any property not explicitly listed still exists, with its default value.
====About "Registers", Marked Here As ®====
As indicated in the listing below, properties are of two types:
* those that can only appear in a property list - not within event handlers - and can only be given an initial unchanging value. Informally, these are like tags.
* those that ''can'' be changed, called "Registers", and indicated here by a ® symbol. These are like true variables.

A Register can be changed by one of these two methods:
# By a "set" or "transition" event handler command, which updates the initial value. If the command is in a different guiDef (while still part of the same GUI), use the "guiDef_name::" prefix before the variable.
# By "binding" a gui:: parameter to it, as its value. This value will then be checked every frame. The value of the gui:: parameter is updated either from an associated .script file, or from a "set" or "transition" command in some guiDef of the GUI. For more, see [[GUI Scripting: GUI:: Parameters]].

While changing a non-register value is not possible, you can probably get the desired effect by cloning the guiDef and selective hiding.

====About Syntax & Usage Examples====
Syntax examples shown here start with how they can appear in a property list. For properties that are registers, there may be additional examples with event handler commands "set", "transition", or "if (condition)". Property list and event handler commands have different syntax; don’t confuse them.

==Used Widely in TDM==
===Rectangle Size, Location, and Appearance===
====backcolor ''color_vector'' ®====
Defines the guiDef’s background color. Colors are normalized RGB and alpha values. . Default: all 0 values (black but transparent).
backcolor 1,1,0,1 // Yellow with no transparency.
====background ''path'' ®====
Defines the guiDef’s background image or video. Typically, this specifies the logical path to a material shader, as defined in a .mtr file. Alternatively, it could be a relative file path, e.g., to a .tga file; the file extension is left off. Default is "".
background "guis/assets/readables/books/book_rightpage_01"
set "background" "guis/video/credits/city_sequence01"; // Logical path shown, defined in materials/tdm_gui.mtr, is to a roq video.
====bordercolor ''color_vector'' ® ====
Defines the color of the guiDef’s border. Colors are normalized RGB and alpha values. The bordersize property must be non-zero for a bordercolor to show. Default: all 1 values (opaque white).
bordercolor 1,1,0,1 // Yellow with no transparency.
bordercolor 0, 0, 0, 0.7 // Used in mainmenu_loadsave.gui. Semi-transparent black border.
====bordersize ''pixels''====
Defines the stroke size used to draw the guiDef’s border, in [presumably logical] pixels. Default: 0.
bordersize 1 // Only sizes 0 and 1 are used in core.
====forceaspectwidth ''width'' & forceaspectheight ''height''====
Force a specific draw surface width and height. Used in a top-level windowDef.

While these commands make only a single appearance in core TDM, in #include file "readables.guicore", that’s within a macro hierarchy affecting all the readables. Default: 640w x 480h.
====matcolor ''color_vector'' ®====
Defines the color of the image displayed in the guiDef’s "background" property. While in a R,G,B,A format, each float is not an absolute color value; it is a percentage (from 0 to 1) of how much of that channel will be rendered. Usually only the A channel is changed. Default: all 1 values (100% rendered).
matcolor 1,1,1,0 // In windowDef backgroundsingle, hide this background initially, then,
set "backgroundsingle::matcolor" "1 1 1 1"; // in a script command, show it right away or fade in.
transition "backgroundsingle::matcolor" "1 1 1 0" "1 1 1 1" READABLE_FADE_TIME;
====modal - see under "Timer and Events"====
====noclip ''bool''====
Don’t clip draw operations that lie outside the guiDef rectangle? Default: 0 (false).
noclip 1 // Widely set to 1 in core, e.g., for readables.
====rect ''vector_with_4_values'' ®====
Defines the location, width and height of the guiDef rectangle as x-origin, y-origin, width, height. 0, 0, 640, 480 would be a guiDef of 640 by 480 logical pixels whose top left corner is at coordinate 0,0. The first two values always represent the guiDef’s upper left corner. The rect of a child guiDef is relative to its parent's rect but within its inner border as given by bordersize. That is, if the parent x/y origin coordinates are 0,0, and the parent's bordersize is 3, then if the child x/y origin coordinates are 0,0, that's actually at the parent's 3,3 location.
rect 0, 0, 640, 480 // By convention, a top-level windowDef is explicitly set to these values, to define the logical coordinate system for child guiDefs.
set "body::rect" "20, 10, 250, 380"; // In guis\readables\parchment_everett_hand_2.gui
transition "message::rect" "0, 0, 185, 1000" "10, 59, 185, 1000" "1" // a script event in tdm_message_no_art.gui that appropriately sizes a popup message box, in this case for 2 lines of text.

====visible ''bool'' ®====
Should this guiDef be visible? Default: 1 (true).
visible 0 // Default is 1 (true). In core, widely used as a toggle.
if ("StealthScoreDetail::visible" == 1) { // Fragment from within mainmenu_success.gui’s
set "StealthScoreDetail::visible" "0"; …} // onAction, showing test and change of value.
===Text and Font Attributes===
====font ''font_path''====
Sets the font to be used for the text, from among available TDM fonts. Default: "".
font "fonts/stone" // Property is widely used in core.
====forecolor ''color_vector'' ®====
Defines the color of the guiDef’s text. Colors are normalized RGB and alpha values. Default: all 1 values (opaque white).
forecolor 1,1,1,1 // This example is opaque white, widely used.
forecolor 0, 0, 0, 0.66 // Black text, semi-transparent, as used for various sign texts.
transition "title::forecolor" "0 0 0 0" "0 0 0 0.85" READABLE_FADE_TIME; // As script command, here to fade in title of a readable sheet of paper.
====text ''string_literal_or_variable'' ®====
The text to be displayed in the guiDef. The character limit is 1024 [true?]. Default: "".
text "Heading" // In property list. Widely used.
text "gui::gui_parm1" // Get desired sign text from spawnarg; used with sign text decals available as prefabs.
set "leftCapital::text" "$gui::left_capital"; // script command used in core for readable books with illuminated drop caps.

====textalign ''align_enum''====
Defines the text’s alignment within the guiDef. Values are 0 (align left), 1 (center horizontally), or 2 (align right). Default: 0 (align left).
textalign 1 // In property list. Value of 1 widely used for centering. Value of 2 rarely, e.g., in tdm_loot.gui .
====textalignx ''offset_x'' & textaligny ''offset_y''====
Offset respectively the x & y value of the text relative to the guiDef. Defaults: 0.
textalignx -3 // mainmenu_defs.gui includes these 2 properties
textaligny -2 // in #defines to properly space button captions.
====textscale ''factor'' ®====
Uniformly scales the text’s font size in the guiDef. The range is generally from 0.0 to 1.0 but can exceed 1.0. Default: 1.
textscale 1.5 // Widely used in readables, ranging from 0.2 to 3.
===Cursor Attributes===
====menugui ''bool''====
Use on a top-level windowDef. A value of 1 marks the gui as a menu gui. This affects the look of the cursor pointer. Helpful too when debugging world guis. Default: 0 (false).
menugui 1 // Value of 1 used in mainmenu.gui, which the #includes all other mainmenu… gui files.
====nocursor ''bool''====
Use on a top-level windowDef. A value of 1 shows no cursor over the windowGui. This can be used for non-interactive GUIs such as videos and in-world monitors. Default: 0 (false).
nocursor 1 // Most HUD and other overlays will set "nocursor 1".
===Timer and Events===
====modal ''bool''====
Should this guiDef eat events if active? Used for pop-up boxes. Default: 0 (false).
modal 1 // Typical use in core: mainmenu_message.gui
====noevents ''bool'' ®====
Should all of the guiDef’s onAction scripts be disabled? Default: 0 (false).
noevents 1
set "noevents" "1" // Representative use in core: in mainmenu_loadsave.gui
====notime ''bool'' ®====
Should all of the guiDef’s onTime scripts be stopped from running? Used for guiDefs holding animation scripts. Default: 0 (false).
notime 1 // Widely used in core.
set "notime" "1"; // Representative use in core: in tdm_inv.gui

==Seldom or Never Used in TDM==
These properties were not found to be used in the core unless otherwise noted with specific examples. Generic examples are given in some cases.
===Rectangle Size, Location, and Appearance===
====invertrect ''bool''====
Correct for this guiDef being upside-down? Default: 0 (false).
invertrect 1 // Not used in core.
====matscalex ''factor_x'' & matscaley ''factor_y''====
Scales the background material in the x & y directions respectively. When set to -1, flips the guiDef’s texture along the horizontal & vertical axis respectively. Default: 1.
matscalex -1 // Used in mainmenu_background when player failed, to flip the texture of "big chains". Matscaley not used in core.
====naturalmatscale ''bool''====
Use the real size of the background material? Default: 0 (false).
naturalmatscale 1 // Not used in core.
====rotate ''degrees'' ®====
Defines the angle in degrees that the guiDef’s image will be rotated. This property can also be used in a "transition" statement to rotate the image over time. Default: 0 degrees.
// Not used in property list in core.
set "rotate" "0"; // Examples from the mainmenu_background.gui, if player fails, rotate a small
transition "rotate" "0" "9" "5000" "0.7" "0.7"; // chain in the background
====shear ''vector_with_2_values''====
"Shear" the rectangle, which turns it into a parallelogram. Range of each value is 0 to 1. Vec2 Default: 0,0.
shear 0.5,0 // Not used in core.
===Text and Font Attributes===
====nowrap ''bool''====
Don’t wrap text that can’t fit in the rectangle? Default: 0 (false), so wrap
nowrap 1
====shadow ''bool''====
Use a black drop-shadow when drawing the text? Default: 0 (false)
shadow 1

''This may actually take an integer, indicating the number of "pixels" offset the shadow is, both rightwards and downwards.''

===Timer and Events===
====wantenter ''bool''====
When the user presses enter, and there's no child guiDef that has the focus, should the guiDef’s onAction (and/or onActionRelease) event handler run? Default: 0 (false)
wantenter 1

==Debug Only==
====showtime ''bool''====
Display the guiDef time? Default: 0 (false).
showtime 1
====showcoords ''bool''====
Display the guiDef coordinates? Default: 0 (false).
showcoords 1

==Unlikely to be Useful==
For more about these properties, likely more pertinent to other idTech4 games, see [[GUI Scripting: TDM vs Doom 3, Quake 4]].
====comment ''string''====
Free form comment area. Unnecessary. Usually, just use /*…*/ or // for comments. Or if this gui is paired with an entity, add a "comment" spawnarg to the latter.
====name ''new_name_string''====
Re-defines the guiDef’s name.. Each guiDef in a GUI file must have a unique name, which by default is initialized by the <guiDef Type> <name> {...}. But can be overwritten by using "name" property explicitly.
====play ''sound_path''====
Prints a warning message telling you not to use it. Main menu system developers: Use 'set "cmd" "play ..." ' instead. Mappers: trigger sounds from a .script or deploy a separate entity.
===Unused in Doom 3 & TDM===
Says Ref 1:

scale®, translate®, varbackground®

runscript® Not available as property, only as script command in Doom 3 (though unused in that form in TDM.)

Listed in Ref 3 (Quake 4), but not in Ref 1:

dpadgui

==For More==
This property listing is largely from Ref 3 of [[GUI Scripting: References & Resources]] as supplemented by Ref 1, but re-ordered. Examples are largely from TDM 2.10 core menus.

{{GUI}}

Carleton Fonts

2026-05-04T17:31:59Z

Geep: revise remarks about black borders

''By Geep, 2025. The analysis here as of TDM 2.12 and for "english" (including European) unless indicated otherwise.''

== The Carleton Family in a Nutshell ==
Carleton is a squarish print-style serif font. The lower case letters look like smaller versions of the upper case letters, so this font can also be referred to as "Carleton Caps", [[Fonts_Screenshots#Carleton_Caps_only | as in this screenshot]]. Within TDM, there are four members of the Carleton family:
* carleton
* carleton_bold
* carleton_condensed (i.e., more tightly spaced in the horizontal dimension)
* carleton_glow

Base-font carleton is used extensively throughout the main menu system. It may appear by itself, in black, for non-interactive subheadings and descriptions. (In a few places, like the "Downloadable Missions" title, a "headline" style using carleton_bold is deployed.)

Or it may participate in dynamic text highlighting for user interactions, using overlay combinations like:
* carleton and carleton_glow
* carleton_bold and carleton_glow, for titles and headlines
* carleton, carleton_bold and carleton_glow, for certain "new game" buttons

For FMs, there are standard readable sheet and scroll prefabs and sign text decals that use carleton, just by itself. The style of this font makes it a good choices for notices; between title and body, and upper and lower case, there can appear to be four different sizes of "capital" letters.

All these usages predominately involve mid-sized and large text (e.g., GUI textscale 0.24 and up), that draws on the 24pt and 48pt size bitmaps. The "english" form of 24pt and 48pt both offer TDM’s full European glyph set. Glyphs are stylishly done for 48pt and not bad for ASCII characters of 24pt; the accented characters of 24pt are rough-hewn and merely adequate.

While 48pt carleton_bold actually has bold (thickened) glyphs, 24pt carleton_bold glyphs are merely copies of regular 24pt carleton, so not bold.

== File Naming and Content Sharing across the Carleton Family ==
The four members share bitmap naming. For instance, if you examine any of the 4 derived fontimage_24.ref files, you see references like:

shaderName fonts/Carleton_0_24.tga

and it will say "Carleton_..." in all cases, not for instance "Carleton_condensed_...". (As is typically the case in TDM, a shader filetype of .tga actually resolves to .dds, and shaderName is case-insensitive; the actual filenames are all lower-case.)

There is also file content sharing (i.e., duplication). As shown in the tables below, the sharing pattern is more complex, and arguably incoherent. This may reflect errors in distribution, or perhaps some member/size combinations not really being used.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 English Carleton Family DAT Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| fontimage_12.dat || SAME || SAME || SAME || SAME
|-
| fontimage_24.dat || SAME || SAME || unique || SAME
|-
| fontimage_48.dat || SAME || SAME || unique || SAME
|}

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Table of 2.12 English Carleton Family DDS Files Sharing File Names and in Some Cases Contents.''' The content of each file is unique, unless shown here by "SAME", which refers to only to matching another file’s content IN THE SAME ROW.
|-
! filename !! /carleton/ !! /carleton_bold/ !! /carleton_condensed/ !! /carleton_glow/
|-
| carleton_0_12.dds || SAME || unique || SAME || unique
|-
| carleton_0_24.dds || '''SAME''' || '''SAME''' || unique || unique
|-
| carleton_1_24.dds || '''SAME''' || '''SAME''' || unique || unique
|-
| carleton_0_48.dds || SAME || unique || SAME || unique
|-
| carleton_1_48.dds || SAME || unique || SAME || unique
|-
| carleton_2_48.dds || SAME || unique || SAME || unique
|-
| carleton_3_48.dds || SAME || unique || SAME || unique
|-
| carleton_4_48.dds || SAME || unique || SAME || unique
|-
| carleton_5_48.dds || SAME || unique || SAME || unique
|-
| carleton_6_48.dds || SAME || unique || SAME || unique
|-
| carleton_7_48.dds || SAME || unique || SAME || unique
|}

== Bitmap File Sizes across the Carleton Family ==
The english 24pt DDS files '''shown in bold above''' have 512x512 bitmaps. All other files (including those for Russian, not in the table) have the default 256x256 bitmaps. This includes carleton_glow. Observe that it is not required that the base & glow have identical bitmap sizes (although that is helpful to allow GIMP layering).

See also [[Refont#Carleton_Family]] for corresponding refont commands.

== Anomalies of Carleton and Carleton Bold 24pt Glyphs ==
As mentioned above, 24pt Carleton Bold is identical to 24pt Carleton; so not really bold. The remaining discussion applies equally to 24pt Carleton and Carleton Bold.

Evidently, the original generation of the 24pt size, into two 256x256 bitmaps "carleton_0_24.dds" and "carleton_1_24.dds", contained only ASCII alphanumeric characters and limited punctuation, with no accented/Latin-1 glyphs. Later, these bitmaps were scaled up to 512x512 bitmaps, to ease drawing in the missing characters by hand. The resulting new characters are coarser than the generated and scaled ASCII characters.

You can see this aspects in the main menu, under Settings/Video/Language, where, in the list of 16 languages, accented letters are thicker.

Also, if viewed in GIMP, the white characters have a faint black border, not seen elsewhere (e.g., in the 48pt bitmaps). This is true of both scaled-up ASCII and drawn Latin-1 characters, though far more prominent in the latter. However, TDM's monochrome, usually black rendering (defined by forecolor in the GUI) obscures the presence of this border effect. The purpose for it is discussed next.

== Carleton When Toggling Choices Within a Submenu ==
Throughout Setting submenus, the Carleton 24pt font is used within option lists. More generally, this presentation style is used for row items within lists.

For example, under Settings/Audio/, there is a row with "Main Menu Music" and a choice of "On" or "Off". This is implemented by a standardized choiceDef.
* On the left, the "Main Menu Music" phrase is carleton, rendered in translucent black (with alpha 0.85) and a textscale of 0.24 (which draws from 24pt).
* On the right, the "On" and "Off" text by default is the same, but slightly smaller at textscale 0.22 (also from 24pt).

When you mouse-hover, the current-value text turns momentarily white with a faint black border. The white is set, not by the GUI, but by the engine's "hoverColor", which is opaque white (1,1,1,1). The black border improves readability against the parchment background. It is due to the "anomolous" black border baked into the font, as discussed above. [Aside: the engine has a "textShadow" boolean and code which presumably could be used to draw a border around a font character. However, "textShadow" is false by default. Unused?]

== Carleton & Carleton Glow in the Main Menu System ==
This pairing occurs basically everywhere thorough the main menu system. In a typical presentation, against a parchment background, major menu-page-selection keywords are by default rendered in black with no glow. But they will turn white with blood-red glow highlighting when either selected (as if a tab for the current page) or moused-over. This will also play a sound and often show a text hint.

=== Example Implementation ===
TDM uses a number of different "button" (i.e., selectable text) styles, driven by #defines in \tdm_gui01\guis\mainmenu_defs.gui. For example, those of the main menu home page use:
#define MM_NORMAL_FONT "fonts/carleton"
#define MM_GLOW_FONT "fonts/carleton_glow"
#define MM_FONTSCALE 0.33
#define MM_BUTTON_HEIGHT 18

For colors, the text is black initially, with glow highlighting invisible. Upon mouse hover, the text becomes white, and the glow red. RGBA colors are defined for this, in vector and string (with S prefix) forms:

#define NORMAL_COLOR 0,0,0,0.90 // black, not entirely opaque
#define SNORMAL_COLOR "0 0 0 0.90"
#define INVISIBLE 0, 0, 0, 0
#define SINVISIBLE "0 0 0 0"
#define GLOW_WHITE_COLOR 0.98,0.93,0.82,1
#define SGLOW_WHITE_COLOR "0.98 0.93 0.82 1"
#define GLOW_RED_COLOR 0.6,0.1,0.1,0.5 // semi-transparent
#define SGLOW_RED_COLOR "0.6 0.1 0.1 0.5"

To be specific, consider a simplified imaginary main menu "button" we'll call "Simple". (We're avoiding the layout calculations and other complications of a real button.) For our button, there are 3 aligned windowDefs in mainmenu_defs.gui, with these locations:

#define MM_POS_SIMPLE_BUTTON rect 40, 445, 160, MM_BUTTON_HEIGHT * 1.3
#define MM_POS_SIMPLE_BUTTON_GLOW rect 41, 446, 159, MM_BUTTON_HEIGHT * 1.3 - 1
#define MM_POS_SIMPLE_ACTION MM_POS_SIMPLE_BUTTON

The windowDefs positioned by these will also do the following:
* MM_POS_SIMPLE_BUTTON: set the default appearance of the button text.
* MM_POS_SIMPLE_BUTTON_GLOW: set the default appearance of the glow "highlight" text. Note this text is offset down and to the right by one pixel, compared to MM_POS_SIMPLE_BUTTON, to give the glow a "drop shadow" flavor. This is a frequent treatment, though in some cases only the right shift is done.
* MM_POS_SIMPLE_ACTION defines the mouse-over and mouse-selection dynamic behaviors. (Be aware that in some actual cases, this is combined into the first windowDef.)

Then, besides the rects, the other attributes are defined for the two default windowDefs:

#define MM_FONT font MM_NORMAL_FONT forecolor SNORMAL_COLOR textscale MM_FONTSCALE visible 1 textalign 1 // centered text
#define MM_FONT_GLOW font MM_GLOW_FONT forecolor INVISIBLE textscale MM_FONTSCALE visible 1 textalign 1

(This is a simplification; for the main menu, MM_FONT's forecolor is #defined as INVISIBLE, then transitions to SNORMAL_COLOR in 1/2 second.)

Within an overall page layout given by mainmenu_main.gui (but with our button shoved in), we might have nested:

windowDef SimpleTextH
{
rect MM_POS_SIMPLE_BUTTON_GLOW
MM_FONT_GLOW
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleText
{
rect MM_POS_SIMPLE_BUTTON
MM_FONT
visible "gui::showSimple"
text "#str_01234" // "Simple"
}
windowDef SimpleAction
{
rect MM_POS_SIMPLE_ACTION
visible "gui::showSimple"
float exit;

onMouseEnter
{
set "exit" 0;
transition "SimpleText::forecolor" SNORMAL_COLOR SGLOW_WHITE_COLOR "50" ;
transition "SimpleTextH::forecolor" SINVISIBLE SGLOW_RED_COLOR "50" ;
set "cmd" "play sound/meta/menu/mnu_hover";
}

onMouseExit
{
if ("exit" == 0)
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;
}
}

onAction
{
transition "SimpleText::forecolor" SGLOW_WHITE_COLOR SNORMAL_COLOR "50" ;
transition "SimpleTextH::forecolor" SGLOW_RED_COLOR SINVISIBLE "50" ;

set "cmd" "play sound/meta/menu/mnu_select;";
set "cmd" "onSimpleClicked"; // tell engine

// And any additional commands here to switch states, resetTime, etc.
}
}

The "H" (highlighted) windowDef is shown first, to draw behind the main text. onMouseEnter turns the text color from black to white in 50 milliseconds, and the glow from invisible to red. onMouseExit reverses that. onAction, when the button is mouse-selected, does the visual transition as mouse exit, but plays a different sound... and then does whatever "Simple" is supposed to do.

== Carleton in Assets for FMs ==
In the tables below, most content has a textscale above 0.30, so draws from the 48pt size, '''indicated in bold'''. Otherwise, with a textscale of 0.16 to 0.30, from 24pt.

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Standard Readable Prefabs.'''
Within \tdm_prefabs01\xdata\prefabs.xd, "gui_page<n>" : "guis/readables/..."
|-
! Prefab !! Title textscale !! Body textscale
|-
| .../books/... none || ||
|-
| .../scrolls/scroll_print_carleton.gui || '''0.40''' || 0.28
|-
| .../sheets/sheet_paper_print_carleton_caps.gui || '''0.40''' || '''0.31'''
|}

{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|+ '''Carleton in Sign Text.''' Within \sign_text_decals\
|-
! Decal !! Textscale
|-
| sign_text_carleton.gui || '''2'''
|-
| sign_text_carleton_small.gui || '''1'''
|}

== Carleton_condensed ==
As indicated above, Carleton_condensed DDS files are all 256x256.

=== 12pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 12pt carleton_condensed (i.e., by specifying a GUI textscale of 0.15 or less). Instead, use regular carleton, possibly with a slightly smaller textscale.''

Although 12pt carleton_condensed exists, its DAT file and single DDS file are mere placeholders that are identical to those of carleton 12pt.

=== 48pt Size ===
''The main menu system does not use this size. In your FM, it is recommended to NOT invoke 48pt carleton_condensed (i.e., by specifying a GUI textscale of above 0.30). Instead, use regular carleton, possibly with a slightly smaller textscale.''

The set of eight DDS files for 48pt carleton_condensed are identical to those for 48pt carleton. However, the DAT file has different content, though the difference is not due to horizontal "condensation".

A one time, Tels drafted a Font Patcher command file for 48pt carleton_condensed, to reduce the width and xSkip of a selected subset of the carleton’s ASCII alphanumeric characters, presumably those most generously spaced to begin with. Evidently this was not finalized and deployed. Instead, inspection of the current 48pt DAT file for carleton_condensed suggests it was based on an early version of carleton, at a time when only some of the accented characters were implemented. (In particular, the DAT lacks re-implemented metrics for chars 128-139 and 145-155.)

=== 24pt Size ===
''The main menu system uses this, but sparingly. Since a "glow" form of carleton_condensed was never developed, only regular non-glow uses are applicable.''

The contents of the DAT file and the set of two DDS files for 48pt carleton_condensed DIFFER from those for 48pt carleton.

For the main menu system, where carleton was used for English-language players, the more-compact carleton_condensed was briefly considered as a method of accommodating European language translations. However, this would require dynamic language switching, and was found to be a hill too far, compared to just reducing Carleton’s textscale value.

The actual limited uses in the main menu systems are seen as you survey the downloadable missions. Specifically, when looking at a candidate mission, the Mission Details page has a Description section, whose body text is carleton_condensed with textscale 0.17. Compared to other similar text section here (that use regular carleton with textscale 0.18), this is slightly smaller and condensed. Also, the Next >> and << Prev buttons for cycling through screenshots have their button captions in this font (with textscale 0.23).

== For More ==
* Character-set coverage of Carleton family is included in the the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

I18N - Charset

2026-05-02T16:19:45Z

Geep: create "Fonts with Special Characters" section

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

This ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

==== Fonts with Special Characters ====
Certain fonts have a few codepoints that purposefully diverge from the table entry.

* Carleton font (regular, bold, glow) uses codepoint 0x23, ordinarily "#", to represent "superscript #", which is used in the main menu system to indicate FMs for which a translation pack is available.
* Treasure Map font has characters for "pirate skull and crossbones" and "bottle of booze (or poison)".

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6.

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14. Similar Stone 48pt and Carleton 24pt improvements are planned for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

ExportUnicodeFontToDoom3

2026-04-01T00:42:21Z

Geep: /* Relationship to Other Parameters */

''By Geep, 2025''

== Introduction ==

In 2025, kalinovka in [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization Font localization] sought to extend TDM’s Mason 48pt font, used in the main menu, to include missing Cyrillic glyphs. This would allow this font to be used in an FM and still support a Russian translation.

This offshoot of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256] is a generalized response to that. The main idea to select an input TTF font that includes not just ASCII or ANSI, but offers additional Unicode characters, like Cyrillic. The program still limits output to a maximum of 256 characters, consistent with the DAT format.

To achieve this, it reads in an external human-readable "unicodeMap" file, in Unicode.org’s "Format A". This format provides a mapping from the traditional 8-bit encoding that TDM uses to the corresponding UCS (Unicode 16-bit) value. Unicode.org provides stock files for standard ISO and Windows 8-bit encodings. Of specific interest here is [https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT cp1251.txt for Cyrillic]. This requires just trivial editing for [https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset TDM-specific codepoints]. As discussed below, you can further edit a unicodeMap file in advance, if you want to generate just a subset of glyphs.

More broadly, this program supersedes ExportFontToDoom3 and ExportFontToDoom3All256.

== New Command Line Arguments ==

These are in-addition to those of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256].

=== unicodeMap <file> ===
Example:

-unicodeMap "./Test/cp1251.txt"

You can edit the unicodeMap file in advance, to specify which particular glyphs you want to generate by suppressing unwanted glyphs, either by:

* Deleting an unwanted line (or block of lines) entirely, or
* Prepending a "#" to comment-out the line.

Also, this file format allows the Unicode value (e.g., "0x1234") to be replaced by 6 space characters, when the ISO or Windows standard leaves that character undefined.

In all 3 of those cases, every suppressed character in the output DAT file will be represented by the glyph that the font uses for U+0000. A hollow box is common.

IMPORTANT: If you edit lines, the remaining active glyph lines MUST be in ascending order by the 2-hex-digit codepoint value that starts each line. Otherwise, results will go astray.

=== startFileNumber <n> ===
When a set of TGA/DDS files are generated for a particular font size, by default the first file's name contains _0_, which increments for additional files. You can optionally specify a different 1- or 2-digit start number, e.g., "-startFileNumber 7". Why? Because...

* the file(s) you are generating are supplemental to, not replacements for, existing TGA/DDS files; and
* in this run, you are generating just one of the 3 possible font sizes (assuming each size has a different count of existing TGA/DDS files).

When you generate a supplemental set, the new DAT file has no knowledge of what's in the original set and its DAT file. You will have to interleave-edit the old and new DAT files (e.g., with reFont's REF files) to create a single DAT file spanning old and new glyphs. There may be a redundant NULL glyph in your new TGA set; just ignore it.

=== awayFromEdge <n> ===

Allows specifying in positive integer pixels (e.g., "-awayFromEdge 2") a small extra boundary at the top and left edges of the overall bitmap. This is for fonts like Mason where extra space (typically 2 pixels) is needed around every character to create a "glow variant". Routine glyph layout provides usually enough space for this except at the top and (arguably) left edges. See also the "compact" parameter.

Note: The spacing value is relative to 256x256 bitmaps. If you specify "hirez", then for proportionality, your specified value is doubled internally when laying out the 512x512 bitmaps.

=== compact ===
If specified (i.e, "-compact"), packs the character glyphs more closely together. Particularly recommended for 48pt fonts; it will generate roughly half the files.

Whether "compact" is specified or not, packing is controlled by simply "padding" each glyph’s bounding box. Specifically, this doesn’t change the bounding box, but adds pixel "padding" to just the right and bottom of the bounding box, a simple though asymmetric process. One reason for padding was given ExportFontToDoom3 author Grant Davies in code comments:

"Because of the way Doom 3 Indexes the texture page (using floating point numbers), it is unable to reference exact pixels – there is error. How much error, I don’t know. For this reason, the rectangles needs to be padded out."

Geep suspects that such error with the TDM engine is not really a problem. Likely some error in the past was due to editing with Q3Font and its low floating-point precision. Nevertheless, some padding is good because:

* For the Mason font, 2 pixels around each glyph are needed for "glow" effects (either done as a separate smudge font for /english/ or as a bidirection offset effect for /russian/.)
* Keeping glyphs separated improves visualization of boundaries with datBounds, and makes editing tweaks easier.

The "compact" setting restores Grant Davies' first algorithm, which just pads the bounding box by 5 pixels to the right and 5 pixels below.

Without "compact", the default is Grant Davies' second algorithm found in ExportFontToDoom3 v1.02. This likewise first pads each bounding box by 5 pixels to the right and 5 pixels below. It then further pads to make both the width and height a factor of 2; this makes 48pt quite sparse. (It is possible this improved rendering performance in 2005; not important now. Also, in practice for major fonts, much of this "factor of 2" spacing was overridden by subsequent Font Patcher work.)

=== hirez or hires ===
''Added with v1.1, March 2026''

Instead of 256x256 bitmaps (and associated DAT), this exports double-sized 512x512 bitmaps with larger, thus potentially-crisper glyphs. (TDM has had a few such 512x512 bitmaps for redrawn fonts since 2014.) Specifically, it:
* outputs requested 512x512 TGAs and their DAT(s).
* internally, doubles the pointsize requested of the TTF, resulting in 2x character glyph sizes. Because both the container bitmap and each glyph is (nominally) doubled in size, the [0...1] s, s2, t, t2 values stored in the DAT would be very similar to those for a 256x256 bitmap.
* Other DAT layout metrics remain as if scaled to a 256x256 layout:
** imageHeight
** imageWidth
** skip
** top (with bottom ignored as usual)
** pitch

For example, if you request –hirez with a carleton font in just 24pt type, it will create 512x512 files with usual names like carleton_0_24.tga, etc., and fontimage_24.dat, with the console showing “Exporting carleton 24pt”.
But internally, 48pt characters are drawn on the bitmaps. The imageHeight and imageWidth metrics will be as if the requested 24pt size was generated, so in effect causing the game engine to scale down by a factor of 2 from the 48pt glyph.

''TIPS on Using a HiRez DAT file''

If subsequently using Refont to make a REF file from this DAT, add the “scaling_ok” option, to suppress otherwise voluminous console warnings about per-character scaling.

If you further plan to generate bounds visualizations with datBounds:
* For 512x512 bitmaps, you must generate from the REF file, not directly from DAT.
* Be sure to first edit the REF to add headers of the form:

# bitmap_<n>_size=512

, where <n> is 0 to 9, and refers to shaders present in the REF file with names like, e.g., carleton_3_48.tga; n would be 3 for this.

* datBounds also has a worthwhile “scaling_ok” option.
* Uncommonly, the raw_metrics option may be of interest.

=== bolding <n> ===
''Added with v1.1, March 2026''

Sometimes, a TTF font does not offer a “bold” variant, or, more generally, a font’s overall stroke thickness is not ideal. It is possible to alter character outlines, then render those as bitmap glyphs.
The result is usually better than post-bitmap thickening or thinning. The FreeType library offers an embolding function for outline alteration, used here.

The integer parameter <n> is in units of 1/64th pixel. A positive value adjusts the outline to embolden the character. Negative thins. The change affects both the overall height and width of the outline.
You may think of the left and bottom character borders as unchanged. The allowed range of <n> is from -128 (i.e., -2 pixels) to 256 (4 pixels). The -2 limit is arbitrary, but for sanity. The 4 limit is the maximum FreeType permits.

Caution: The adjustment algorithm moves the outline controls points, but doesn't change the number of such points;
this means that certain situations like acute angles or intersections are sometimes handled incorrectly.

=== inPlace <filename of input layout file> ===
''This experimental feature, new in v 1.2, reads a DAT file for input layout. It may be extended to REF and FTN filetypes in the future. Specifications are subject to change.''

Rather than having an algorithm decide where each glyph should go within a set of bitmaps, this option lets a pre-existing layout file determine it. This is designed to be used with only one point size at a time, so deploy it in conjunction with the “-size” parameter.
This is helpful in building up aligned layers in a GIMP file, particularly as a step in making a “hybrid” or composite TDM font from multiple sources.
This forces a particular layout, great as a “first draft”, but improvable with further bitmap and DAT editing. You can expect some glyph collisions will occur; perhaps incrementally manage this by suppressing some glyphs with a custom unicodeMap?

====File Generation & Naming====
The number of TGA files created, and their names, and their references in the output DAT, will exactly match that specified by the input layout file.
To avoid confusion or name conflict between input and output layout files, either rename the input file, e.g., from “fontimage_24.dat” to “fontimage_24_in.dat”, or place the input layout file in a separate child directory, e.g., “placeAt/fontimage_24.dat”

====Glyph Alignment & Placement====
During placement, for each glyph, only 4 input DAT values are used:
* s
* t
* top
* shaderName

The rest are derived from the TTF file, as influenced by other command-line parameters. Specifically, an output glyph is aligned with the baseline and left-boundary of the corresponding input glyph. That is, the upper-left origin of the output glyph is given by (s, t+top_input-top_TTF), placed into bitmap “shaderName”. (Exception: Negative origin coordinates are replaced by zero.) Aligning vertically by baseline in this way seemed more helpful than aligning by t value alone.

If a codepoint requested by the input DAT has no glyph in the TTF, this codepoint will be skipped during output, i.e., no empty box is generated in its place... because the empty box just gets in the way during subsequent GIMP work. Exception: Codepoint 0x0000 does generate an empty box.

====Relationship to Other Parameters====
These are required:
* The input TTF filename (in addition to inPlace's input layout file; as noted, the contents of the latter file will determine what TGA files are generated.)
* The size <fontsize> option. As usual, this will determine the font size requested from the TTF file, as well as the name of the output fontImage_<filesize>.dat file. However, unlike the usual case, not the naming of the output TGA files.

These options are optional:
* unicodeMap <filename>
* hirez [with DAT file as input, to generate 512x512 output files; situation may change with future REF file.]
* bolding <value>
* name <alternative font name>. As usual, this will name the (generated if necessary) folder into which output files are placed. However, unlike the usual case, the naming of the output TGA files will be as given in the input DAT file.

These options are ignored, by design:
* compact [whether present or absent; no algorithimic layout applied.]
* awayFromEdge <value>

This option is probably problematic and should be avoided for now:
* startFileNumber

== Changed Behavior for Font Title from ExportFontToDoom3All256 ==
In ExportFontToDoom3All256, if the font title was more that 20 characters long, it would truncate it to fit in the DAT file as part of the shader names (i.e., paths to TGA files). But this threshold was wrong. Now, truncation and a warning happens if the font title is more that 17 characters long (or 16 if generated TGAs include any with a 2-digit count instead of 1-digit). If truncation occurs, the user is asked to consider using or revising the -name argument.

== Downloads ==
Release v1.2 of 2025-03-31 ''(which adds inPlace option; makes clearer a command-line message about xOffset and pitch).''
* [https://drive.google.com/file/d/1CG_BXsTTYi7E3nQPKtBWi-94Cj3R5eOY/view?usp=sharing ExportUnicodeFontToDoom3_release_1_2_exe.zip] . Windows binary and required archived versions of FreeType and DevIL DLLs.
* [https://drive.google.com/file/d/1Nw4RdKKx2YHoPR6D-YQzdnEFx-vyYUhk/view?usp=sharing ExportUnicodeFontToDoom3_release_1_2_source_project.zip] . The C++ project file with source code, including source & build project of archived library.

Release v1.1 of 2025-03-03:
* [https://drive.google.com/file/d/1f3Jj53qtJGIp0_mz7Riing9Fi8ESFDr5/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_exe.zip]
* [https://drive.google.com/file/d/1nutMBfcIWw63wNTUdnlnzP397tGVpnpd/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_source_project.zip] .

Release 1 of 2024-09-10:
* [https://drive.google.com/file/d/1MqoOfhc5-ovoxoHfRquYAcIEdHEOJAQV/view?usp=sharing ExportUnicodeFontToDoom3_release_1_exe.zip]
* [https://drive.google.com/file/d/1Frk_byfdtCcMqdr27ulw1XyuFj8vYp9x/view?usp=sharing ExportUnicodeFontToDoom3_release_1_source_project.zip]

== See Also ==
The Cyrillic coverage of Lora Regular TTF font, projected to used as Russian Mason supplement in TDM 2.14, may be viewed and font downloaded [https://www.fontsquirrel.com/fonts/lora?filter%5Bclassifications%5D%5B0%5D=serif&filter%5Blanguages%5D%5B0%5D=cyrillic#eula here].

ExportUnicodeFontToDoom3

2026-04-01T00:41:57Z

Geep: /* Relationship to Other Parameters */

''By Geep, 2025''

== Introduction ==

In 2025, kalinovka in [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization Font localization] sought to extend TDM’s Mason 48pt font, used in the main menu, to include missing Cyrillic glyphs. This would allow this font to be used in an FM and still support a Russian translation.

This offshoot of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256] is a generalized response to that. The main idea to select an input TTF font that includes not just ASCII or ANSI, but offers additional Unicode characters, like Cyrillic. The program still limits output to a maximum of 256 characters, consistent with the DAT format.

To achieve this, it reads in an external human-readable "unicodeMap" file, in Unicode.org’s "Format A". This format provides a mapping from the traditional 8-bit encoding that TDM uses to the corresponding UCS (Unicode 16-bit) value. Unicode.org provides stock files for standard ISO and Windows 8-bit encodings. Of specific interest here is [https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT cp1251.txt for Cyrillic]. This requires just trivial editing for [https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset TDM-specific codepoints]. As discussed below, you can further edit a unicodeMap file in advance, if you want to generate just a subset of glyphs.

More broadly, this program supersedes ExportFontToDoom3 and ExportFontToDoom3All256.

== New Command Line Arguments ==

These are in-addition to those of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256].

=== unicodeMap <file> ===
Example:

-unicodeMap "./Test/cp1251.txt"

You can edit the unicodeMap file in advance, to specify which particular glyphs you want to generate by suppressing unwanted glyphs, either by:

* Deleting an unwanted line (or block of lines) entirely, or
* Prepending a "#" to comment-out the line.

Also, this file format allows the Unicode value (e.g., "0x1234") to be replaced by 6 space characters, when the ISO or Windows standard leaves that character undefined.

In all 3 of those cases, every suppressed character in the output DAT file will be represented by the glyph that the font uses for U+0000. A hollow box is common.

IMPORTANT: If you edit lines, the remaining active glyph lines MUST be in ascending order by the 2-hex-digit codepoint value that starts each line. Otherwise, results will go astray.

=== startFileNumber <n> ===
When a set of TGA/DDS files are generated for a particular font size, by default the first file's name contains _0_, which increments for additional files. You can optionally specify a different 1- or 2-digit start number, e.g., "-startFileNumber 7". Why? Because...

* the file(s) you are generating are supplemental to, not replacements for, existing TGA/DDS files; and
* in this run, you are generating just one of the 3 possible font sizes (assuming each size has a different count of existing TGA/DDS files).

When you generate a supplemental set, the new DAT file has no knowledge of what's in the original set and its DAT file. You will have to interleave-edit the old and new DAT files (e.g., with reFont's REF files) to create a single DAT file spanning old and new glyphs. There may be a redundant NULL glyph in your new TGA set; just ignore it.

=== awayFromEdge <n> ===

Allows specifying in positive integer pixels (e.g., "-awayFromEdge 2") a small extra boundary at the top and left edges of the overall bitmap. This is for fonts like Mason where extra space (typically 2 pixels) is needed around every character to create a "glow variant". Routine glyph layout provides usually enough space for this except at the top and (arguably) left edges. See also the "compact" parameter.

Note: The spacing value is relative to 256x256 bitmaps. If you specify "hirez", then for proportionality, your specified value is doubled internally when laying out the 512x512 bitmaps.

=== compact ===
If specified (i.e, "-compact"), packs the character glyphs more closely together. Particularly recommended for 48pt fonts; it will generate roughly half the files.

Whether "compact" is specified or not, packing is controlled by simply "padding" each glyph’s bounding box. Specifically, this doesn’t change the bounding box, but adds pixel "padding" to just the right and bottom of the bounding box, a simple though asymmetric process. One reason for padding was given ExportFontToDoom3 author Grant Davies in code comments:

"Because of the way Doom 3 Indexes the texture page (using floating point numbers), it is unable to reference exact pixels – there is error. How much error, I don’t know. For this reason, the rectangles needs to be padded out."

Geep suspects that such error with the TDM engine is not really a problem. Likely some error in the past was due to editing with Q3Font and its low floating-point precision. Nevertheless, some padding is good because:

* For the Mason font, 2 pixels around each glyph are needed for "glow" effects (either done as a separate smudge font for /english/ or as a bidirection offset effect for /russian/.)
* Keeping glyphs separated improves visualization of boundaries with datBounds, and makes editing tweaks easier.

The "compact" setting restores Grant Davies' first algorithm, which just pads the bounding box by 5 pixels to the right and 5 pixels below.

Without "compact", the default is Grant Davies' second algorithm found in ExportFontToDoom3 v1.02. This likewise first pads each bounding box by 5 pixels to the right and 5 pixels below. It then further pads to make both the width and height a factor of 2; this makes 48pt quite sparse. (It is possible this improved rendering performance in 2005; not important now. Also, in practice for major fonts, much of this "factor of 2" spacing was overridden by subsequent Font Patcher work.)

=== hirez or hires ===
''Added with v1.1, March 2026''

Instead of 256x256 bitmaps (and associated DAT), this exports double-sized 512x512 bitmaps with larger, thus potentially-crisper glyphs. (TDM has had a few such 512x512 bitmaps for redrawn fonts since 2014.) Specifically, it:
* outputs requested 512x512 TGAs and their DAT(s).
* internally, doubles the pointsize requested of the TTF, resulting in 2x character glyph sizes. Because both the container bitmap and each glyph is (nominally) doubled in size, the [0...1] s, s2, t, t2 values stored in the DAT would be very similar to those for a 256x256 bitmap.
* Other DAT layout metrics remain as if scaled to a 256x256 layout:
** imageHeight
** imageWidth
** skip
** top (with bottom ignored as usual)
** pitch

For example, if you request –hirez with a carleton font in just 24pt type, it will create 512x512 files with usual names like carleton_0_24.tga, etc., and fontimage_24.dat, with the console showing “Exporting carleton 24pt”.
But internally, 48pt characters are drawn on the bitmaps. The imageHeight and imageWidth metrics will be as if the requested 24pt size was generated, so in effect causing the game engine to scale down by a factor of 2 from the 48pt glyph.

''TIPS on Using a HiRez DAT file''

If subsequently using Refont to make a REF file from this DAT, add the “scaling_ok” option, to suppress otherwise voluminous console warnings about per-character scaling.

If you further plan to generate bounds visualizations with datBounds:
* For 512x512 bitmaps, you must generate from the REF file, not directly from DAT.
* Be sure to first edit the REF to add headers of the form:

# bitmap_<n>_size=512

, where <n> is 0 to 9, and refers to shaders present in the REF file with names like, e.g., carleton_3_48.tga; n would be 3 for this.

* datBounds also has a worthwhile “scaling_ok” option.
* Uncommonly, the raw_metrics option may be of interest.

=== bolding <n> ===
''Added with v1.1, March 2026''

Sometimes, a TTF font does not offer a “bold” variant, or, more generally, a font’s overall stroke thickness is not ideal. It is possible to alter character outlines, then render those as bitmap glyphs.
The result is usually better than post-bitmap thickening or thinning. The FreeType library offers an embolding function for outline alteration, used here.

The integer parameter <n> is in units of 1/64th pixel. A positive value adjusts the outline to embolden the character. Negative thins. The change affects both the overall height and width of the outline.
You may think of the left and bottom character borders as unchanged. The allowed range of <n> is from -128 (i.e., -2 pixels) to 256 (4 pixels). The -2 limit is arbitrary, but for sanity. The 4 limit is the maximum FreeType permits.

Caution: The adjustment algorithm moves the outline controls points, but doesn't change the number of such points;
this means that certain situations like acute angles or intersections are sometimes handled incorrectly.

=== inPlace <filename of input layout file> ===
''This experimental feature, new in v 1.2, reads a DAT file for input layout. It may be extended to REF and FTN filetypes in the future. Specifications are subject to change.''

Rather than having an algorithm decide where each glyph should go within a set of bitmaps, this option lets a pre-existing layout file determine it. This is designed to be used with only one point size at a time, so deploy it in conjunction with the “-size” parameter.
This is helpful in building up aligned layers in a GIMP file, particularly as a step in making a “hybrid” or composite TDM font from multiple sources.
This forces a particular layout, great as a “first draft”, but improvable with further bitmap and DAT editing. You can expect some glyph collisions will occur; perhaps incrementally manage this by suppressing some glyphs with a custom unicodeMap?

====File Generation & Naming====
The number of TGA files created, and their names, and their references in the output DAT, will exactly match that specified by the input layout file.
To avoid confusion or name conflict between input and output layout files, either rename the input file, e.g., from “fontimage_24.dat” to “fontimage_24_in.dat”, or place the input layout file in a separate child directory, e.g., “placeAt/fontimage_24.dat”

====Glyph Alignment & Placement====
During placement, for each glyph, only 4 input DAT values are used:
* s
* t
* top
* shaderName

The rest are derived from the TTF file, as influenced by other command-line parameters. Specifically, an output glyph is aligned with the baseline and left-boundary of the corresponding input glyph. That is, the upper-left origin of the output glyph is given by (s, t+top_input-top_TTF), placed into bitmap “shaderName”. (Exception: Negative origin coordinates are replaced by zero.) Aligning vertically by baseline in this way seemed more helpful than aligning by t value alone.

If a codepoint requested by the input DAT has no glyph in the TTF, this codepoint will be skipped during output, i.e., no empty box is generated in its place... because the empty box just gets in the way during subsequent GIMP work. Exception: Codepoint 0x0000 does generate an empty box.

====Relationship to Other Parameters====
These are required:
* The input TTF filename (in addition to inPlace's input layout file; as noted, the contents of the latter file will determine what TGA files are generated.)
* The size <fontsize> option. As usual, this will determine the font size requested from the TTF file, as well as the name of the output fontImage_<filesize>.dat file. However, unlike the usual case, not the naming of the output TGA files.

These options are optional:
* unicodeMap <filename>
* hirez [with DAT file as input, to generate 512x512 output files; situation may change with future REF file.]
* bolding <value>
* name <alternative font name>. As usual, this will name the (generated if necessary) folder into which output files are placed. However, unlike the usual case, the naming of the output TGA files will be as given in the input DAT file.

These options are ignored, by design:
* compact [whether present or absent; no algorithimic layout applied.]
* awayFromEdge <value>

Thes option is probably problematic and should be avoided for now:
* startFileNumber

== Changed Behavior for Font Title from ExportFontToDoom3All256 ==
In ExportFontToDoom3All256, if the font title was more that 20 characters long, it would truncate it to fit in the DAT file as part of the shader names (i.e., paths to TGA files). But this threshold was wrong. Now, truncation and a warning happens if the font title is more that 17 characters long (or 16 if generated TGAs include any with a 2-digit count instead of 1-digit). If truncation occurs, the user is asked to consider using or revising the -name argument.

== Downloads ==
Release v1.2 of 2025-03-31 ''(which adds inPlace option; makes clearer a command-line message about xOffset and pitch).''
* [https://drive.google.com/file/d/1CG_BXsTTYi7E3nQPKtBWi-94Cj3R5eOY/view?usp=sharing ExportUnicodeFontToDoom3_release_1_2_exe.zip] . Windows binary and required archived versions of FreeType and DevIL DLLs.
* [https://drive.google.com/file/d/1Nw4RdKKx2YHoPR6D-YQzdnEFx-vyYUhk/view?usp=sharing ExportUnicodeFontToDoom3_release_1_2_source_project.zip] . The C++ project file with source code, including source & build project of archived library.

Release v1.1 of 2025-03-03:
* [https://drive.google.com/file/d/1f3Jj53qtJGIp0_mz7Riing9Fi8ESFDr5/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_exe.zip]
* [https://drive.google.com/file/d/1nutMBfcIWw63wNTUdnlnzP397tGVpnpd/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_source_project.zip] .

Release 1 of 2024-09-10:
* [https://drive.google.com/file/d/1MqoOfhc5-ovoxoHfRquYAcIEdHEOJAQV/view?usp=sharing ExportUnicodeFontToDoom3_release_1_exe.zip]
* [https://drive.google.com/file/d/1Frk_byfdtCcMqdr27ulw1XyuFj8vYp9x/view?usp=sharing ExportUnicodeFontToDoom3_release_1_source_project.zip]

== See Also ==
The Cyrillic coverage of Lora Regular TTF font, projected to used as Russian Mason supplement in TDM 2.14, may be viewed and font downloaded [https://www.fontsquirrel.com/fonts/lora?filter%5Bclassifications%5D%5B0%5D=serif&filter%5Blanguages%5D%5B0%5D=cyrillic#eula here].

ExportUnicodeFontToDoom3

2026-04-01T00:40:14Z

Geep: /* Downloads */ updates to release 1.2

''By Geep, 2025''

== Introduction ==

In 2025, kalinovka in [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization Font localization] sought to extend TDM’s Mason 48pt font, used in the main menu, to include missing Cyrillic glyphs. This would allow this font to be used in an FM and still support a Russian translation.

This offshoot of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256] is a generalized response to that. The main idea to select an input TTF font that includes not just ASCII or ANSI, but offers additional Unicode characters, like Cyrillic. The program still limits output to a maximum of 256 characters, consistent with the DAT format.

To achieve this, it reads in an external human-readable "unicodeMap" file, in Unicode.org’s "Format A". This format provides a mapping from the traditional 8-bit encoding that TDM uses to the corresponding UCS (Unicode 16-bit) value. Unicode.org provides stock files for standard ISO and Windows 8-bit encodings. Of specific interest here is [https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT cp1251.txt for Cyrillic]. This requires just trivial editing for [https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset TDM-specific codepoints]. As discussed below, you can further edit a unicodeMap file in advance, if you want to generate just a subset of glyphs.

More broadly, this program supersedes ExportFontToDoom3 and ExportFontToDoom3All256.

== New Command Line Arguments ==

These are in-addition to those of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256].

=== unicodeMap <file> ===
Example:

-unicodeMap "./Test/cp1251.txt"

You can edit the unicodeMap file in advance, to specify which particular glyphs you want to generate by suppressing unwanted glyphs, either by:

* Deleting an unwanted line (or block of lines) entirely, or
* Prepending a "#" to comment-out the line.

Also, this file format allows the Unicode value (e.g., "0x1234") to be replaced by 6 space characters, when the ISO or Windows standard leaves that character undefined.

In all 3 of those cases, every suppressed character in the output DAT file will be represented by the glyph that the font uses for U+0000. A hollow box is common.

IMPORTANT: If you edit lines, the remaining active glyph lines MUST be in ascending order by the 2-hex-digit codepoint value that starts each line. Otherwise, results will go astray.

=== startFileNumber <n> ===
When a set of TGA/DDS files are generated for a particular font size, by default the first file's name contains _0_, which increments for additional files. You can optionally specify a different 1- or 2-digit start number, e.g., "-startFileNumber 7". Why? Because...

* the file(s) you are generating are supplemental to, not replacements for, existing TGA/DDS files; and
* in this run, you are generating just one of the 3 possible font sizes (assuming each size has a different count of existing TGA/DDS files).

When you generate a supplemental set, the new DAT file has no knowledge of what's in the original set and its DAT file. You will have to interleave-edit the old and new DAT files (e.g., with reFont's REF files) to create a single DAT file spanning old and new glyphs. There may be a redundant NULL glyph in your new TGA set; just ignore it.

=== awayFromEdge <n> ===

Allows specifying in positive integer pixels (e.g., "-awayFromEdge 2") a small extra boundary at the top and left edges of the overall bitmap. This is for fonts like Mason where extra space (typically 2 pixels) is needed around every character to create a "glow variant". Routine glyph layout provides usually enough space for this except at the top and (arguably) left edges. See also the "compact" parameter.

Note: The spacing value is relative to 256x256 bitmaps. If you specify "hirez", then for proportionality, your specified value is doubled internally when laying out the 512x512 bitmaps.

=== compact ===
If specified (i.e, "-compact"), packs the character glyphs more closely together. Particularly recommended for 48pt fonts; it will generate roughly half the files.

Whether "compact" is specified or not, packing is controlled by simply "padding" each glyph’s bounding box. Specifically, this doesn’t change the bounding box, but adds pixel "padding" to just the right and bottom of the bounding box, a simple though asymmetric process. One reason for padding was given ExportFontToDoom3 author Grant Davies in code comments:

"Because of the way Doom 3 Indexes the texture page (using floating point numbers), it is unable to reference exact pixels – there is error. How much error, I don’t know. For this reason, the rectangles needs to be padded out."

Geep suspects that such error with the TDM engine is not really a problem. Likely some error in the past was due to editing with Q3Font and its low floating-point precision. Nevertheless, some padding is good because:

* For the Mason font, 2 pixels around each glyph are needed for "glow" effects (either done as a separate smudge font for /english/ or as a bidirection offset effect for /russian/.)
* Keeping glyphs separated improves visualization of boundaries with datBounds, and makes editing tweaks easier.

The "compact" setting restores Grant Davies' first algorithm, which just pads the bounding box by 5 pixels to the right and 5 pixels below.

Without "compact", the default is Grant Davies' second algorithm found in ExportFontToDoom3 v1.02. This likewise first pads each bounding box by 5 pixels to the right and 5 pixels below. It then further pads to make both the width and height a factor of 2; this makes 48pt quite sparse. (It is possible this improved rendering performance in 2005; not important now. Also, in practice for major fonts, much of this "factor of 2" spacing was overridden by subsequent Font Patcher work.)

=== hirez or hires ===
''Added with v1.1, March 2026''

Instead of 256x256 bitmaps (and associated DAT), this exports double-sized 512x512 bitmaps with larger, thus potentially-crisper glyphs. (TDM has had a few such 512x512 bitmaps for redrawn fonts since 2014.) Specifically, it:
* outputs requested 512x512 TGAs and their DAT(s).
* internally, doubles the pointsize requested of the TTF, resulting in 2x character glyph sizes. Because both the container bitmap and each glyph is (nominally) doubled in size, the [0...1] s, s2, t, t2 values stored in the DAT would be very similar to those for a 256x256 bitmap.
* Other DAT layout metrics remain as if scaled to a 256x256 layout:
** imageHeight
** imageWidth
** skip
** top (with bottom ignored as usual)
** pitch

For example, if you request –hirez with a carleton font in just 24pt type, it will create 512x512 files with usual names like carleton_0_24.tga, etc., and fontimage_24.dat, with the console showing “Exporting carleton 24pt”.
But internally, 48pt characters are drawn on the bitmaps. The imageHeight and imageWidth metrics will be as if the requested 24pt size was generated, so in effect causing the game engine to scale down by a factor of 2 from the 48pt glyph.

''TIPS on Using a HiRez DAT file''

If subsequently using Refont to make a REF file from this DAT, add the “scaling_ok” option, to suppress otherwise voluminous console warnings about per-character scaling.

If you further plan to generate bounds visualizations with datBounds:
* For 512x512 bitmaps, you must generate from the REF file, not directly from DAT.
* Be sure to first edit the REF to add headers of the form:

# bitmap_<n>_size=512

, where <n> is 0 to 9, and refers to shaders present in the REF file with names like, e.g., carleton_3_48.tga; n would be 3 for this.

* datBounds also has a worthwhile “scaling_ok” option.
* Uncommonly, the raw_metrics option may be of interest.

=== bolding <n> ===
''Added with v1.1, March 2026''

Sometimes, a TTF font does not offer a “bold” variant, or, more generally, a font’s overall stroke thickness is not ideal. It is possible to alter character outlines, then render those as bitmap glyphs.
The result is usually better than post-bitmap thickening or thinning. The FreeType library offers an embolding function for outline alteration, used here.

The integer parameter <n> is in units of 1/64th pixel. A positive value adjusts the outline to embolden the character. Negative thins. The change affects both the overall height and width of the outline.
You may think of the left and bottom character borders as unchanged. The allowed range of <n> is from -128 (i.e., -2 pixels) to 256 (4 pixels). The -2 limit is arbitrary, but for sanity. The 4 limit is the maximum FreeType permits.

Caution: The adjustment algorithm moves the outline controls points, but doesn't change the number of such points;
this means that certain situations like acute angles or intersections are sometimes handled incorrectly.

=== inPlace <filename of input layout file> ===
''This experimental feature, new in v 1.2, reads a DAT file for input layout. It may be extended to REF and FTN filetypes in the future. Specifications are subject to change.''

Rather than having an algorithm decide where each glyph should go within a set of bitmaps, this option lets a pre-existing layout file determine it. This is designed to be used with only one point size at a time, so deploy it in conjunction with the “-size” parameter.
This is helpful in building up aligned layers in a GIMP file, particularly as a step in making a “hybrid” or composite TDM font from multiple sources.
This forces a particular layout, great as a “first draft”, but improvable with further bitmap and DAT editing. You can expect some glyph collisions will occur; perhaps incrementally manage this by suppressing some glyphs with a custom unicodeMap?

====File Generation & Naming====
The number of TGA files created, and their names, and their references in the output DAT, will exactly match that specified by the input layout file.
To avoid confusion or name conflict between input and output layout files, either rename the input file, e.g., from “fontimage_24.dat” to “fontimage_24_in.dat”, or place the input layout file in a separate child directory, e.g., “placeAt/fontimage_24.dat”

====Glyph Alignment & Placement====
During placement, for each glyph, only 4 input DAT values are used:
* s
* t
* top
* shaderName

The rest are derived from the TTF file, as influenced by other command-line parameters. Specifically, an output glyph is aligned with the baseline and left-boundary of the corresponding input glyph. That is, the upper-left origin of the output glyph is given by (s, t+top_input-top_TTF), placed into bitmap “shaderName”. (Exception: Negative origin coordinates are replaced by zero.) Aligning vertically by baseline in this way seemed more helpful than aligning by t value alone.

If a codepoint requested by the input DAT has no glyph in the TTF, this codepoint will be skipped during output, i.e., no empty box is generated in its place... because the empty box just gets in the way during subsequent GIMP work. Exception: Codepoint 0x0000 does generate an empty box.

====Relationship to Other Parameters====
These are required:
* The input TTF filename (in addition to inPlace's input layout file; as noted, the contents of the latter file will determine what TGA files are generated.)
* The size <fontsize> option. As usual, this will determine the font size requested from the TTF file, as well as the name of the output fontImage_<filesize>.dat file. However, unlike the usual case, not the naming of the output TGA files.

These options are optional:
* unicodeMap <filename>
* hirez [with DAT file as input, to generate 512x512 output files; situation may change with future REF file.]
* bolding <value>
* name <alternative font name>. As usual, this will name the (generated if necessary) folder into which output files are placed. However, unlike the usual case, the naming of the output TGA files will be as given in the input DAT file.

These options are ignored, by design:
* compact [whether present or absent; no algorithimic layout applied.]
* awayFromEdge <value>

Theis option is probably problematic and should be avoided for now:
* startFileNumber

== Changed Behavior for Font Title from ExportFontToDoom3All256 ==
In ExportFontToDoom3All256, if the font title was more that 20 characters long, it would truncate it to fit in the DAT file as part of the shader names (i.e., paths to TGA files). But this threshold was wrong. Now, truncation and a warning happens if the font title is more that 17 characters long (or 16 if generated TGAs include any with a 2-digit count instead of 1-digit). If truncation occurs, the user is asked to consider using or revising the -name argument.

== Downloads ==
Release v1.2 of 2025-03-31 ''(which adds inPlace option; makes clearer a command-line message about xOffset and pitch).''
* [https://drive.google.com/file/d/1CG_BXsTTYi7E3nQPKtBWi-94Cj3R5eOY/view?usp=sharing ExportUnicodeFontToDoom3_release_1_2_exe.zip] . Windows binary and required archived versions of FreeType and DevIL DLLs.
* [https://drive.google.com/file/d/1Nw4RdKKx2YHoPR6D-YQzdnEFx-vyYUhk/view?usp=sharing ExportUnicodeFontToDoom3_release_1_2_source_project.zip] . The C++ project file with source code, including source & build project of archived library.

Release v1.1 of 2025-03-03:
* [https://drive.google.com/file/d/1f3Jj53qtJGIp0_mz7Riing9Fi8ESFDr5/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_exe.zip]
* [https://drive.google.com/file/d/1nutMBfcIWw63wNTUdnlnzP397tGVpnpd/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_source_project.zip] .

Release 1 of 2024-09-10:
* [https://drive.google.com/file/d/1MqoOfhc5-ovoxoHfRquYAcIEdHEOJAQV/view?usp=sharing ExportUnicodeFontToDoom3_release_1_exe.zip]
* [https://drive.google.com/file/d/1Frk_byfdtCcMqdr27ulw1XyuFj8vYp9x/view?usp=sharing ExportUnicodeFontToDoom3_release_1_source_project.zip]

== See Also ==
The Cyrillic coverage of Lora Regular TTF font, projected to used as Russian Mason supplement in TDM 2.14, may be viewed and font downloaded [https://www.fontsquirrel.com/fonts/lora?filter%5Bclassifications%5D%5B0%5D=serif&filter%5Blanguages%5D%5B0%5D=cyrillic#eula here].

ExportUnicodeFontToDoom3

2026-03-31T21:24:13Z

Geep: Add inPlace option

''By Geep, 2025''

== Introduction ==

In 2025, kalinovka in [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization Font localization] sought to extend TDM’s Mason 48pt font, used in the main menu, to include missing Cyrillic glyphs. This would allow this font to be used in an FM and still support a Russian translation.

This offshoot of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256] is a generalized response to that. The main idea to select an input TTF font that includes not just ASCII or ANSI, but offers additional Unicode characters, like Cyrillic. The program still limits output to a maximum of 256 characters, consistent with the DAT format.

To achieve this, it reads in an external human-readable "unicodeMap" file, in Unicode.org’s "Format A". This format provides a mapping from the traditional 8-bit encoding that TDM uses to the corresponding UCS (Unicode 16-bit) value. Unicode.org provides stock files for standard ISO and Windows 8-bit encodings. Of specific interest here is [https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT cp1251.txt for Cyrillic]. This requires just trivial editing for [https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset TDM-specific codepoints]. As discussed below, you can further edit a unicodeMap file in advance, if you want to generate just a subset of glyphs.

More broadly, this program supersedes ExportFontToDoom3 and ExportFontToDoom3All256.

== New Command Line Arguments ==

These are in-addition to those of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256].

=== unicodeMap <file> ===
Example:

-unicodeMap "./Test/cp1251.txt"

You can edit the unicodeMap file in advance, to specify which particular glyphs you want to generate by suppressing unwanted glyphs, either by:

* Deleting an unwanted line (or block of lines) entirely, or
* Prepending a "#" to comment-out the line.

Also, this file format allows the Unicode value (e.g., "0x1234") to be replaced by 6 space characters, when the ISO or Windows standard leaves that character undefined.

In all 3 of those cases, every suppressed character in the output DAT file will be represented by the glyph that the font uses for U+0000. A hollow box is common.

IMPORTANT: If you edit lines, the remaining active glyph lines MUST be in ascending order by the 2-hex-digit codepoint value that starts each line. Otherwise, results will go astray.

=== startFileNumber <n> ===
When a set of TGA/DDS files are generated for a particular font size, by default the first file's name contains _0_, which increments for additional files. You can optionally specify a different 1- or 2-digit start number, e.g., "-startFileNumber 7". Why? Because...

* the file(s) you are generating are supplemental to, not replacements for, existing TGA/DDS files; and
* in this run, you are generating just one of the 3 possible font sizes (assuming each size has a different count of existing TGA/DDS files).

When you generate a supplemental set, the new DAT file has no knowledge of what's in the original set and its DAT file. You will have to interleave-edit the old and new DAT files (e.g., with reFont's REF files) to create a single DAT file spanning old and new glyphs. There may be a redundant NULL glyph in your new TGA set; just ignore it.

=== awayFromEdge <n> ===

Allows specifying in positive integer pixels (e.g., "-awayFromEdge 2") a small extra boundary at the top and left edges of the overall bitmap. This is for fonts like Mason where extra space (typically 2 pixels) is needed around every character to create a "glow variant". Routine glyph layout provides usually enough space for this except at the top and (arguably) left edges. See also the "compact" parameter.

Note: The spacing value is relative to 256x256 bitmaps. If you specify "hirez", then for proportionality, your specified value is doubled internally when laying out the 512x512 bitmaps.

=== compact ===
If specified (i.e, "-compact"), packs the character glyphs more closely together. Particularly recommended for 48pt fonts; it will generate roughly half the files.

Whether "compact" is specified or not, packing is controlled by simply "padding" each glyph’s bounding box. Specifically, this doesn’t change the bounding box, but adds pixel "padding" to just the right and bottom of the bounding box, a simple though asymmetric process. One reason for padding was given ExportFontToDoom3 author Grant Davies in code comments:

"Because of the way Doom 3 Indexes the texture page (using floating point numbers), it is unable to reference exact pixels – there is error. How much error, I don’t know. For this reason, the rectangles needs to be padded out."

Geep suspects that such error with the TDM engine is not really a problem. Likely some error in the past was due to editing with Q3Font and its low floating-point precision. Nevertheless, some padding is good because:

* For the Mason font, 2 pixels around each glyph are needed for "glow" effects (either done as a separate smudge font for /english/ or as a bidirection offset effect for /russian/.)
* Keeping glyphs separated improves visualization of boundaries with datBounds, and makes editing tweaks easier.

The "compact" setting restores Grant Davies' first algorithm, which just pads the bounding box by 5 pixels to the right and 5 pixels below.

Without "compact", the default is Grant Davies' second algorithm found in ExportFontToDoom3 v1.02. This likewise first pads each bounding box by 5 pixels to the right and 5 pixels below. It then further pads to make both the width and height a factor of 2; this makes 48pt quite sparse. (It is possible this improved rendering performance in 2005; not important now. Also, in practice for major fonts, much of this "factor of 2" spacing was overridden by subsequent Font Patcher work.)

=== hirez or hires ===
''Added with v1.1, March 2026''

Instead of 256x256 bitmaps (and associated DAT), this exports double-sized 512x512 bitmaps with larger, thus potentially-crisper glyphs. (TDM has had a few such 512x512 bitmaps for redrawn fonts since 2014.) Specifically, it:
* outputs requested 512x512 TGAs and their DAT(s).
* internally, doubles the pointsize requested of the TTF, resulting in 2x character glyph sizes. Because both the container bitmap and each glyph is (nominally) doubled in size, the [0...1] s, s2, t, t2 values stored in the DAT would be very similar to those for a 256x256 bitmap.
* Other DAT layout metrics remain as if scaled to a 256x256 layout:
** imageHeight
** imageWidth
** skip
** top (with bottom ignored as usual)
** pitch

For example, if you request –hirez with a carleton font in just 24pt type, it will create 512x512 files with usual names like carleton_0_24.tga, etc., and fontimage_24.dat, with the console showing “Exporting carleton 24pt”.
But internally, 48pt characters are drawn on the bitmaps. The imageHeight and imageWidth metrics will be as if the requested 24pt size was generated, so in effect causing the game engine to scale down by a factor of 2 from the 48pt glyph.

''TIPS on Using a HiRez DAT file''

If subsequently using Refont to make a REF file from this DAT, add the “scaling_ok” option, to suppress otherwise voluminous console warnings about per-character scaling.

If you further plan to generate bounds visualizations with datBounds:
* For 512x512 bitmaps, you must generate from the REF file, not directly from DAT.
* Be sure to first edit the REF to add headers of the form:

# bitmap_<n>_size=512

, where <n> is 0 to 9, and refers to shaders present in the REF file with names like, e.g., carleton_3_48.tga; n would be 3 for this.

* datBounds also has a worthwhile “scaling_ok” option.
* Uncommonly, the raw_metrics option may be of interest.

=== bolding <n> ===
''Added with v1.1, March 2026''

Sometimes, a TTF font does not offer a “bold” variant, or, more generally, a font’s overall stroke thickness is not ideal. It is possible to alter character outlines, then render those as bitmap glyphs.
The result is usually better than post-bitmap thickening or thinning. The FreeType library offers an embolding function for outline alteration, used here.

The integer parameter <n> is in units of 1/64th pixel. A positive value adjusts the outline to embolden the character. Negative thins. The change affects both the overall height and width of the outline.
You may think of the left and bottom character borders as unchanged. The allowed range of <n> is from -128 (i.e., -2 pixels) to 256 (4 pixels). The -2 limit is arbitrary, but for sanity. The 4 limit is the maximum FreeType permits.

Caution: The adjustment algorithm moves the outline controls points, but doesn't change the number of such points;
this means that certain situations like acute angles or intersections are sometimes handled incorrectly.

=== inPlace <filename of input layout file> ===
''This experimental feature, new in v 1.2, reads a DAT file for input layout. It may be extended to REF and FTN filetypes in the future. Specifications are subject to change.''

Rather than having an algorithm decide where each glyph should go within a set of bitmaps, this option lets a pre-existing layout file determine it. This is designed to be used with only one point size at a time, so deploy it in conjunction with the “-size” parameter.
This is helpful in building up aligned layers in a GIMP file, particularly as a step in making a “hybrid” or composite TDM font from multiple sources.
This forces a particular layout, great as a “first draft”, but improvable with further bitmap and DAT editing. You can expect some glyph collisions will occur; perhaps incrementally manage this by suppressing some glyphs with a custom unicodeMap?

====File Generation & Naming====
The number of TGA files created, and their names, and their references in the output DAT, will exactly match that specified by the input layout file.
To avoid confusion or name conflict between input and output layout files, either rename the input file, e.g., from “fontimage_24.dat” to “fontimage_24_in.dat”, or place the input layout file in a separate child directory, e.g., “placeAt/fontimage_24.dat”

====Glyph Alignment & Placement====
During placement, for each glyph, only 4 input DAT values are used:
* s
* t
* top
* shaderName

The rest are derived from the TTF file, as influenced by other command-line parameters. Specifically, an output glyph is aligned with the baseline and left-boundary of the corresponding input glyph. That is, the upper-left origin of the output glyph is given by (s, t+top_input-top_TTF), placed into bitmap “shaderName”. (Exception: Negative origin coordinates are replaced by zero.) Aligning vertically by baseline in this way seemed more helpful than aligning by t value alone.

If a codepoint requested by the input DAT has no glyph in the TTF, this codepoint will be skipped during output, i.e., no empty box is generated in its place... because the empty box just gets in the way during subsequent GIMP work. Exception: Codepoint 0x0000 does generate an empty box.

====Relationship to Other Parameters====
These are required:
* The input TTF filename (in addition to inPlace's input layout file; as noted, the contents of the latter file will determine what TGA files are generated.)
* The size <fontsize> option. As usual, this will determine the font size requested from the TTF file, as well as the name of the output fontImage_<filesize>.dat file. However, unlike the usual case, not the naming of the output TGA files.

These options are optional:
* unicodeMap <filename>
* hirez [with DAT file as input, to generate 512x512 output files; situation may change with future REF file.]
* bolding <value>
* name <alternative font name>. As usual, this will name the (generated if necessary) folder into which output files are placed. However, unlike the usual case, the naming of the output TGA files will be as given in the input DAT file.

These options are ignored, by design:
* compact [whether present or absent; no algorithimic layout applied.]
* awayFromEdge <value>

Theis option is probably problematic and should be avoided for now:
* startFileNumber

== Changed Behavior for Font Title from ExportFontToDoom3All256 ==
In ExportFontToDoom3All256, if the font title was more that 20 characters long, it would truncate it to fit in the DAT file as part of the shader names (i.e., paths to TGA files). But this threshold was wrong. Now, truncation and a warning happens if the font title is more that 17 characters long (or 16 if generated TGAs include any with a 2-digit count instead of 1-digit). If truncation occurs, the user is asked to consider using or revising the -name argument.

== Downloads ==
Release v1.2 of 2025-03-31
* [REAL SOON]

Release v1.1 of 2025-03-03:
* [https://drive.google.com/file/d/1f3Jj53qtJGIp0_mz7Riing9Fi8ESFDr5/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_exe.zip] . Windows binary and required archived versions of FreeType and DevIL DLLs.
* [https://drive.google.com/file/d/1nutMBfcIWw63wNTUdnlnzP397tGVpnpd/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_source_project.zip] . The C++ project file with source code, including source & build project of archived library.

Release 1 of 2024-09-10:
* [https://drive.google.com/file/d/1MqoOfhc5-ovoxoHfRquYAcIEdHEOJAQV/view?usp=sharing ExportUnicodeFontToDoom3_release_1_exe.zip]
* [https://drive.google.com/file/d/1Frk_byfdtCcMqdr27ulw1XyuFj8vYp9x/view?usp=sharing ExportUnicodeFontToDoom3_release_1_source_project.zip]

== See Also ==
The Cyrillic coverage of Lora Regular TTF font, projected to used as Russian Mason supplement in TDM 2.14, may be viewed and font downloaded [https://www.fontsquirrel.com/fonts/lora?filter%5Bclassifications%5D%5B0%5D=serif&filter%5Blanguages%5D%5B0%5D=cyrillic#eula here].

Refont

2026-03-21T22:16:13Z

Geep: /* Downloads */ Add comments about 2.7, 2.8 improvements

''By Geep, 2024, and similar to the article about Q3Font.''

Introduced in 2024, the "refont" command-line utility allows inspection and alteration of [[Font Metrics & DAT File Format | font metrics]].
It is designed to be an easier-to-use version of the inspection/alteration functionalities of [[Q3Font]].
It also provides a font analysis feature.

== Comparison with Font Patcher ==

Refont can be seen as complementary to [[Font Patcher]]. The latter has additional features that may be better if planning a wholesale rearrangement or expansion of characters within a bitmap, particularly for a new font immediately after conversion from a TTF font. But refont is easier to use in later years, and Font Patcher requires installation of Perl, while refont.exe is more drop and go.

== Comparison with Q3Font ==

For metric alteration, q3font has a native "*.fnt" human-readable format, and supports DAT <==> FNT conversions. For compatibility, so does refont.

=== Advantages of Q3Font ===

* This has been an important traditional tool for Doom3/TDM font manipulation.
* In addition to production/consumption of FNT, it -
** Allows creation of DAT & TGA files from a TrueType font (although for this purpose, [[ExportFontToDoom3]] has been preferred in practice).
** Can write (but not read) an alternative "compact report".

=== Advantages of Refont ===

* It's open-source, so further C++ development is possible.
* It has its own native human-readable format, "*.ref", similar to .fnt but better.
* The REF format can be read by [[datBounds]] to generate bitmap boundary & metrics visualizations.

The better features of REF are:

* Codepoints are enumerated in not just decimal, but also hex.
* Coordinates of the overall image box within its bitmap are expressed in pixel units, rather than [0...1] fractional floating point. So the user is spared having to manually do this tedious and error-prone calculation.
* This overcomes a drawback of FNT, that expresses the coordinates with only 6 digits after the decimal point, not quite enough to avoid minor mis-precisions.
* if optionally provided, a separate, read-only annotation file will automatically decorate the .ref file with helpful information as the file is generated. This is explained below.

Because the code is open-source, there's better clarity about -
* how parsing and calculations are done.
* what warnings are emitted.

Also, using "-stats", refont can write (but not read) an analysis of a DAT file, particularly looking for problematic/unimplemented Western-language characters.

== For Inspection & Correction of DAT files ==

''To Get the Data in Readable, Editable Form''

For viewing and altering in a text editor, two formats are provided. Both list every codepoint, in order from 0 to 255, as a block of data. Within each block, every item gets its own line.

=== As a FNT File ===

To create a q3font-compatable "<dat-name>.fnt" file:

refont -decompile <path to given .dat file> -fnt

where the path can be a full path, a relative path (e.g., starting with "./" or "../"), or just the file name in the current working directory. The resulting .fnt file will appear in the same directory. It have the same name as the .dat file, except for the extension. As a convenience to keep track of versions, it is not required that the file name be in the standard fontImage_nn.dat form.

Example code block for the letter A:
...
char 65
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
s 0.769531
t 0.250000
s2 0.847656
t2 0.320313
glyph 0
shaderName fonts/stone_0_24.tga
}
...

Note that Q3Font FNT expresses the s, t, s2, and t2 coordinates with only 6 digits after the decimal point, causing minor low-precision rounding during DAT --> FNT --> DAT roundtrips. For compatibility, Refont FNT does likewise.

=== As a REF File ===
''Starting with Refont v2.5, a mixture of 256x256 and 512x512 bitmap shaders, encountered with Carleton and Mason family fonts, can be handled. See further below.''

To create a refont-specific "<dat-name>.ref" file:

refont -decompile <path to given .dat file>

The same path and naming conventions as for .fnt generation discussed above apply here.

Example code block for the letter A when no supplemental annotation file is present (nor any per-line comments, e.g., with warnings):

...
char 65 (0x41)
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 197
coord_t 64
coord_s2 217
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

Items bolded differ from FNT format. The starting line expresses the value in hex. And rather than s, t, s2, t2 in fractional [0...1] floating point, the "coord_..." values are expressed (and editable) as integer coordinates of the bitmap, with a range reflecting bitmap size. The default TDM bitmap size is 256x256, but a few fonts use 512x512 and require special treatment discussed further below.

== When Editing ==
Refont has a minimal parser. To keep it happy, preserve the file's line structure. In particular:
* every REF and FNT file has the same number of lines. ''(Exception: REF may have additional starting lines to flag 512x512 bitmaps, discussed below. Generally, you won't edit these.)''
* all keywords within a block must be present, and in a particular order.
* each block must have exactly the same number of lines (except for the special one at the end).

The meaning of the font metrics are explained in [[Font_Metrics_%26_DAT_File_Format]]. The [[Q3Font]] article has an example of simple metric editing that is also pertinent to refont.

== To Move Changed FNT or REF Data Back to a DAT ==

refont -compile <path to given .fnt or .ref file>

This reverses the -decompile process, to create a .dat file whose name is derived from the .fnt or .ref file. Importantly, this decompile/compile cycle leaves .tga/.dds files untouched.

== The Annotation File ==
When told to generate a REF file (but not FNT), refont.exe also looks for a file called "refont_char_annotations.txt", in the same folder as refont.exe. That file should have exactly 256 data lines in it, one for each of the codepoints, in order. As the REF is generated, the line that starts a codepoint's data block gets the corresponding annotation line appended to it. Having the annotations come from an external file, instead of hard-coded into refont, allows required flexibility as to what information is presented. It even potentially allows refont to be used with other idTech3/4 games that don't necessarily used the TDM-specific codepoints. Also, the annotation files contain helpful specific comments (as lines that start with ";").

Each annotation:
* indicates what character symbol is ''expected''; it is oblivious as to what character if any is actually within the bounding box described by the DAT data.
* lives only in a REF file, and is not retained when converted to a DAT file. This also true for any manual supplementary annotations you might make.

This is clearer with examples. In 'Downloads' below are 4 different versions of "refont_char_annotations[...].txt". Three of these, specific to TDM's custom 'english' (i.e., composite European) codepage, are discussed here. To deploy, edit the filename of one of them to remove the square bracket text.

=== English with Symbol Only ===

This simple format is best for most purposes. The file entry for letter 'A' is just:

A

Then the block in a generated REF file would have that string appended, but with " // " inserted.
...
char 65 (0x41) // A
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 197
coord_t 64
coord_s2 217
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

=== English with Unicode-16 Codes and Names ===

This supplies the Unicode Consortium's official 16-bit codepoints (where U+NNNN = 0xNNNN) and their names, in the formal all-caps convention.

The file entry for letter 'A' is:

U+0041 LATIN CAPITAL LETTER A

Then the first line of the corresponding block in a generated REF file would show:
...
char 65 (0x41) // U+0041 LATIN CAPITAL LETTER A
...
Here's another example from that REF:
...
char 129 (0x81) // U+015A LATIN CAPITAL LETTER S WITH ACUTE
...
For control or TDM undefined characters, this annotation file assumes a hollow box glyph is the appropriate mapping:
...
char 0 (0x00) // U+24A1 WHITE SQUARE
...
But there are other choices, so edit the annotation file as you see fit.
=== English with 8859-x Source ===

This verbose format may be useful during font analysis. For letters that are in their expected locations as defined by ASCII or ISO 8859-1 (Latin-1) or Windows-1252 ("Western Europe"), the annotation is fairly minimal. Thus, letter 'A' has this:

0x41 is A

(TIP: If authoring your own annotation file, consider including a codepoint number on each line, like "0x41" here, to make the process easier.)

Then the first line of the corresponding block in a generated REF file would show:
...
char 65 (0x41) // 0x41 is A
...
Here are a few more interesting examples from that REF, with more expansive annotations:
...
char 5 (0x05) // 0x05 is a control character, unusable in TDM
...
char 166 (0xa6) // 0xA6 is Š (not ISO 8859-1 ¦) (from A9 in ISO 8859-2) (TDM only)
...

== Revising or Making Your Own Annotations File ==
If creating your own refont_char_annotations.txt file, note that encoding upper-range characters in UTF-8 will be more universal than using Windows region-specific codepages. To enter a UTF-8 character using its four digit hex Unicode (say, in a range of interest 0x0080-0x00FF):
* Under Windows, type the four hex digits followed by Alt-X.
* Under Linux, hold down Ctrl+Shift, type U followed by the 4 digits; release Ctrl+Shift.

When refont reads refont_char_annotations.txt, any line that starts with ";" will be ignored. The latter is so that you can put comments into the file, that will not propagate to the generated REF file. TIP: If such commenting is unwanted, start the line with <space> before ";".

Other than that, be sure to have exactly 256 lines of annotations (though refont will check and issue a warning if not). A line can be empty, i.e., have only the linebreak.

When generating a REF file, refont will automatically add " // " before each non-empty annotation, so don't include that.

== Adding Your Own Annotations to a REF File ==
Beyond the refont_char_annotation.txt content, you can add certain commentary to the REF file without it affecting its ability to convert to a DAT file. Here are the rules:
* Don't add or subtract lines, or comment out non-blank lines
* Feel free to append a comment to the end of a line, by beginning the comment with " //".
* Likewise, on a line starting with "char" that had an annotation automatically added, you can revise the annotation as you see fit.

Example with revision in bold:
...
char 65 (0x41) // '''Capital A was slightly clipped. Decremented s, s2 by 1. Looks OK now.'''
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 196 '''// WAS: 197'''
coord_t 64
coord_s2 216 '''// WAS: 217'''
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

In this way, you can markup a REF file as a record of work to do, work in progress, or work completed.

==Errors, Warnings, and Auto-Corrections==
''This covers the major overhaul of Refont v 2.1, and its added options -no_warn_comments and -scaling_ok.''

During the compile or decompile, errors and warnings may be generated in the console. Fatal errors are largely due to:
* file I/O problems;
* deviations from the strict DAT, REF, and FNT formats.

Warnings, which are not fatal, are largely due to anomolous numeric values. The TDM engine can tolerant some of these, so they don't necessarily need fixing.

===Fatal Errors when Parsing REF or FNT as Input===
A fatal error, due to divergence from the expected format while parsing, stops the program. While potentially due to many causes (e.g., adding or deleting lines), errors will be reported - with line number - as failures of:

''Variable Name Checks.'' The parser expects every variable name in a particular order. A mismatch happened.

''Integer Checks.'' Integer value was unparsable, or out of range for integer type. Checked for per-character variables height, top, bottom, pitch, xSkip, imageWidth, imageHeight, and glyph. Plus REF’s coord_s, coord_t, coord_s2, and coord_ t2.

''Float Checks.'' Floating point value was unparsable, or out of range for float type. Checked for glyphScale, and FNT’s per-character variables s, t, s2, t2.

===Post-Read MAJOR Warnings about REF, FNT, and DAT Input Values===
After parsing, the input process concludes with a separate loop of non-fatal warning analysis. Warnings during input, broadly categorized as major or minor, report to the console, but don’t do any value corrections (which is instead left to the subsequent file-write stage).

''For FNT’s and DAT’s s, t, s2, t2''
* Inexact Integer. The given bounding box value, expected in the range 0-1, when multiplied by 256.0 should be exactly an integer. If not, the divergence is likely due to miscalculation. (Actually, a divergence from an integer of under +/- 0.001 is tolerated by Refont and considered a minor warning, discussed below.)
* Float Out of Range 0.0 - 1.0. Or equivalently, post-multiplication, 0.0 - 256.0. (See the discussion of the edge cases under minor warnings below.)

''For Other Metrics of DAT, FNT, and REF''
* Integer Out of Range 0-256. For height, top, bottom, pitch, xSkip, imageWidth, imageHeight, and REF’s coord_s, coord_t, coord_s2, and coord_t2.
* Integer Non Zero. For glyph.
* Float Less Than Zero. For glyphScale (which is independent of a particular character).
* Inconsistent Metrics. For a given character, this compares two metrics and looks for inconsistencies. We’ll state this here in REF terms, e.g., using “coord_s” rather than “ROUND_TO_INT(s * 256.0f)”:
** imageHeight == height?
** imageWidth == coord_s2 - coord_s?
** imageHeight == coord_t2 - coord_t?

However, warnings about those last two "Inconsistent Metrics" criteria are suppressed if:
* you use refont's "-scaling_ok" option. This is helpful when there is extensive per-character scaling. (Only TDM’s mason and mason-glow use a lot of per-character scaling, specifically for all upper-case characters.)
* you have a 512x512 bitmap, where throughout, the imageWidth and imageHeight (and some other metrics) are expected to be scaled to "half" of the corresponding coord difference. As of refont 2.8, 1 pixel of wiggle-room is allowed for integer rounding. Only warnings will be issued that fail these checks:
** abs(imageWidth * 2 - (coord_s2 - coord_s)) > 1
** abs(imageHeight * 2 - (coord_t2 - coord_t)) > 1

===Post-Read MINOR Warnings for FNT’s and DAT’s s, t, s2, t2===
''Low Precision.'' This value, when multiplied by 256.0, should be exactly an integer. However, some generation or revision procedure (e.g., Q3Font’s DAT  FNT  DAT) may have not used sufficient precision to ensure this. An offset from an integer value of less than +/- 0.001 is considered a minor problem; otherwise, major as above.

This problem, when it occurs with a file, typically happens a lot. Consequently, it is not reported in an itemized way, but instead, the console will show total counts of affected characters and values.

Edge cases: a value of {s, s2, t, or t2} * 256.0 that is negative but closer to zero than -0.001000 is considered this type of minor problem (and is not considered out of range, which would be major). Likewise, if that value is greater than 256.000000, but less than 256.001000
===Automatic Corrections during Output to a REF File===
Certain problems, first detected during DAT input, are further addressed at write time. Because these problems were already reported to the console during the DAT read, nothing additional is written to console. Instead, there may be reporting within the REF file itself.

''Automatic Corrections.'' When writing a REF file, the integer values of coord_s, coord_t, coord_s2, and coord_t2 are calculated from DAT floats s, t, s2, and t2 respectively. A calculated coord_... value, if not already resulting in an integer, is automatically forced to the nearest integer. This is so whether it was earlier reported to the console as a Major or Minor Warning. (Before refont v 2.1, the REF might assign an unrounded decimal value; no longer true.)

''Warnings Not Automatically Corrected.'' Automatic fixing of other warnings is unwise and not offered. Why? Because the fix is not obvious or complex, and sometimes, the corresponding character glyph in the bitmap needs adjustment. This pertains to Major Warnings about:
* Integer values outside their expected range (e.g., 0-256), including post-rounding coord_... values.
* Inconsistent Metrics
===Generated Within-REF Comments during Output===
For most causes of a Major Warning during DAT read, during subsequent writing of the REF file, a similar comment is also generated within the REF, on the same line as the parameter assignment. For example:
char 95 (0x5f) // _
{
...
top -6 // WARNING: Not in range 0-256. Does bitmap or other metrics need adjusting?
...
}
...
char 140 (0x8c) // Ń
{
...
coord_t -10 // WARNING: Underlying DAT value -0.03906250, * 256.0 gave -10.000000000, not in range 0-256 once rounded. Does bitmap or other metrics need adjusting?
...
}
''Suppressing Comment Generation.'' Use the refont option “-no_warn_comments”. ''New to v 2.1.''

TIP: When editing a REF file with comments, you can keep them, change them, or delete them as you prefer. They have no impact on subsequent compiles to DAT.

''Coverage of Generated Within-REF Comments.'' A calculated value of coord_s, coord_t, coord_s2, or coord_t2 would have been flagged as a “Major Warning” during read if:
* the discrepancy from being an integer was non-trivial (+/- 0.001 or more), or
* the calculated and rounded integer is outside the range given by bitmap size, e.g., 0-256.

For these, a comment is generated. Other causes are:
* Integer Out of Range 0-256 ''(or 0-512 as applicable)''. For height, top, bottom, pitch, xSkip, imageWidth, imageHeight.
* Integer Non Zero. For glyph.
* Float Less Than Zero. For glyphScale (which is independent of a particular character).

''Major Warnings that Don’t Cause Within-REF Comments.'' Currently, this is limited to “Inconsistent Metrics”, which would probably require tagging on multiple lines.

== Special Handling of Fonts with 512x512 Bitmaps ==
Some DAT files reference bitmap shaders where some or all are of size 512x512, instead of the default 256x256. Refont v2.5+ can support this (replacing an insufficient first attempt in v2.4).

Font developers went to double-sized bitmaps to:
* in the case of Carleton, allow freehand drawing of missing European characters, which could be drawn more easily if twice standard size.
* in the case of Mason, have larger ASCII alphanumeric glyphs that would render with crisper edges.

In either case, the font characters when rendered in, say, the game main menu will be the same size as if from 256x256. This is because the imageWidth, imageHeight, height, and top metrics are not doubled.
In effect, a scaling by half (approximately, as constrained by integer values) is requested for all characters in the DAT file and applied by the engine.

=== When generating a REF file from a DAT file ===

refont -decompile <path to given .dat file> -512_<n> ''where <n> is a single digit, e.g. '1' in referenced shader name "font/Carleton_1_24.tga" ''

You should use multiple instances of the -512_<n> option, to cover all the 512x512 bitmaps found in the DAT file.

If ''all'' of a given DATs shaders are 512x512, you can use this shorter form:

refont -decompile <path to given .dat file> -512

Exercising -512... options will mean that in the generated REF file:

* There will be a one or more starting lines like:
# bitmap_<n>_size=512 ''(Refont will look for this if doing a subsequent compile to DAT)''
* If you specified the short form, it will expand to just the right number of starting lines.
* Values for coord_s, coord_s2, coord_t, and coord_t2 will have a normal range of 0-512 when appropriate. [COMING SOON: Those values may then be read properly by datBounds.].
* Any warnings expressed (within the file or within the command-line window) will be in terms of the correct range of values.
* Warning checks will expect a scaling by half for all characters. That is, while 512... requires scaling down by half, that scaling will not generate a warning (unless it's not EXACTLY by half, or within 1 pixel of that), so the -scaling_ok option is not needed just for the exactly-by-half scaling.

=== When generating a DAT file from a REF file ===

During refont -compile, no special command line options are needed. Instead, REF's starting lines of form "# bitmap_<n>_size=512" are inspected and coord ranges will be interpreted as 0-512 whenever appropriate.

=== Special Handling Recommendations for Carleton and Mason ===
''For fonts shipped with TDM 2.12 in tdm_fonts01.pk4. Illustrative command paths are shown; adjust to your working copy.''
==== Mason Family ====
The [[Mason Font]] uses within-DAT per-character scaling, as well as some but not all 512x512 bitmaps. Only 48pt Mason is shipped.

Because, under /dds/fonts/english/mason/, bitmaps masonalternate_0_48.dds to _2_ are 512x512, but _3_ to _5_ are not, use:

-decompile /fonts/english/mason/fontimage_48.dat -512_0 -512_1 -512_2 -scaling_ok

Because, under /dds/fonts/english/mason_glow/, bitmaps masonalternate_1_48.dds and _2_ are 512x512, but _0_ and _3_ to _5_ are not, use:

-decompile /fonts/english/mason_glow/fontimage_48.dat -512_1 -512_2 -scaling_ok

Russian versions use the default 256x256. [These possibly benefit from -scaling_ok; didn't investigate.]
==== Carleton Family ====
The 24pt size of carleton has two bitmaps under /dds/fonts/english/carleton/, namely carleton_0_24.dds and _1_, both of size 512x512. So use:

-decompile /fonts/english/carleton/fontimage_24.dat -512_0 -512_1
''or''
-decompile /fonts/english/carleton/fontimage_24.dat -512

The 24pt size of carleton_bold has bitmaps with identical content to carleton's, so use the same options:

-decompile /fonts/english/carleton_bold/fontimage_24.dat -512_0 -512_1
''or''
-decompile /fonts/english/carleton_bold/fontimage_24.dat -512

Other members of this family use the default 256x256 bitmaps:
* Sizes 12pt & 48pt
* carleton_condensed and carleton_glow. (Note: while helpful, it is not required that the base & glow have identical bitmap sizes.)
* Russian versions

==== These Fonts with Stats ====
With -stats discussed next, if reading a DAT file, you may use the -512... and scaling_ok options to be most correct, although neglecting to specify them will likely have no significant impact on the analytical results. If reading a REF file, the included "# bitmap_..." lines will take care of that for you.

== For Statistics on Unimplemented or Problematic Font Characters ==
DAT or (as of v2.3) REF file analysis here is primarily designed to benefit english/european fonts. It will use the optional annotation file if provided. Syntax:

refont -stats <path to given .dat or .ref file>

Use "-stats" by itself, not combined with "-compile" or "-decompile".

The resulting analysis report will have the same name and location as the input file, but with a ".txt" suffix.
The report provides categorized totals and (for problematic characters) itemizations across all 256 character codepoints.
The counts of problems should be considered minimums, since no inspection of bitmap files (TGA or DDS) is done.
But a perhaps surprising amount of insight can be gleaned just from DAT/REF file metrics.
Itemizations include annotations from the 'ref_char_annotation' file, if provided.

In the hunt for missing characters, 3 signatures are important:

* Presumed 'Hollow Box' = glyph's 'shadername' is <fontname>_0_<size>.dds only, and s & t are zero, but not s2 & t2
* '<Space>' = same test as 'Hollow Box', but pointed to by char 32 (0x20)
* 'Zero Box' = No glyph box (s, t, s2, t2 all zero)

A given analysis will assume either 'Hollow Box' or '<Space>' but not both.

The analysis provides totals and itemizations - grouped into lower (0-127) and upper ranges (128-255) - in several passes:

* Pass 1 - Handling of unprintable/unsupported/missing codepoints, indicated by Hollow Box, Zero Box, or <Space>. Some of these are not a problem, but some are tagged as "Undesirable".
* Pass 2 - Bad glyph box (negative s, t, s2, or t2; or s2 <= s, t2 <= t) or good glyph box with dubious metrics (imageHeight <= 0, imageWidth <=0, imageHeight != height). Excludes those already counted as "Undesirable" in Pass 1.
* Pass 3 - Detection of duplicate glyph boxes (other than Hollow Box, Zero Box, or <Space>). Detected by: glyph's values for shadername, s, t, s2, & t2 exactly match those of another codepoint. These are grouped into "Dup Sets".

Then, across passes 1-3, a count if given of the minimum "Total Glyphs Needing Work".

Refont version 2.3 adds additional passes:

* Pass 4 - Reports "Overlap Sets" rather than just "Dup Sets". A set here may include an unaccented "base character" that has been serving as a substitute work-around target for one or more missing accented characters. (What constitutes an "overlap" is idiosyncratic; see the source code for details.)
* Pass 5 - Same information as Pass 4, but sorted first by shader name (i.e., bitmap). Helpful for organizing bitmap-editing work.
* Pass 6 - An analysis focusing just on the planned migration of duplicate O/o-circumflex codepoints to G/g-cup glyphs.

== Downloads ==
Release 2.8 of March 19, 2026:
* Supports partial coverage regeneration (i.e., unicodeMap with not all 256 represented) by ExportUnicodeFontToDoom3.
* With 512x512 bitmaps, suppresses scaling warnings if scaled by "half", now +/- 1 pixel.
* [https://drive.google.com/file/d/1BHGkCOhgXP7bFp1mXyfgoRBUtqkbCVRb/view?usp=sharing refont.exe]
* [https://drive.google.com/file/d/1Cca_Xo3W5jYB_40RVo4aIPHAGIufA9V0/view?usp=sharing refont_source_v2.8.zip, with refont.cpp, refont.sln, open-source license]

Version 2.7: Fixes poor detection of _<n>_ pattern in shadername, and allow <n> to be 1 or 2 digits, not just 1.

Release 2.6 of July 28, 2025:
* [https://drive.google.com/file/d/1ABf4771Jr1C1hKbLx4xWq8lx8Kn7HdKP/view?usp=sharing refont.exe]
* [https://drive.google.com/file/d/1-k68eo0CHKZ-sM7JGP05axm49cc5De0T/view?usp=sharing source code: refont.cpp]

===Annotations===
''After download, to use any one of these, edit filename to remove "[...]" substring.''

Update of June 20, 2024. This reflects a change to the TDM charmap for 2.13, to replace duplicate O/o circumflex characters with G/g breve:

* refont_char_annotations[english with symbol only. With G-breve update].txt [https://drive.google.com/file/d/1rrt-O9DgD7Zn2Hxt7nBtViIlO4kv_gQB/view?usp=sharing here]. Recommended for most purposes with 'english' fonts.
* refont_char_annotations[english with Unicode-16 codes & names. With G-breve update].txt [https://drive.google.com/file/d/1AMxDKQc_DE33gsExiEkGp3x67eb4aGFh/view?usp=sharing here].
* refont_char_annotations[english with 8859-x source. With G-breve update].txt [https://drive.google.com/file/d/1xoeZ1poTbmkls-gE5PnbbMxdoz5KnMD7/view?usp=sharing].
* For Russian, see the previous update next.

Update of April 13, 2024:

* refont_char_annotations[english with symbol only].txt [https://drive.google.com/file/d/1ItM-aXps0xQE655HdaJM7Aje5lHewUfC/view?usp=sharing here]. Recommended for most purposes with 'english' fonts.
* refont_char_annotations[english with Unicode-16 codes and names].txt [https://drive.google.com/file/d/1gW7oO_wLqCEPSdm6b05OaTNYHnyuUSA-/view?usp=sharing here].
* refont_char_annotations[english with 8859-x source].txt [https://drive.google.com/file/d/1ZTcgA4QJYwXzNdqbolYkn0CCEDILD1bX/view?usp=sharing here]. Corrects and supersedes original english file.
* refont_char_annotations[russian].txt [https://drive.google.com/file/d/10txNXsSCtaTiT2iGT9o3iDxBU7HVYNxi/view?usp=sharing here]. Recommended for 'russian' fonts.

== For More ==
* See the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

Refont

2026-03-19T17:46:28Z

Geep: /* Downloads */ v 2.8 released

''By Geep, 2024, and similar to the article about Q3Font.''

Introduced in 2024, the "refont" command-line utility allows inspection and alteration of [[Font Metrics & DAT File Format | font metrics]].
It is designed to be an easier-to-use version of the inspection/alteration functionalities of [[Q3Font]].
It also provides a font analysis feature.

== Comparison with Font Patcher ==

Refont can be seen as complementary to [[Font Patcher]]. The latter has additional features that may be better if planning a wholesale rearrangement or expansion of characters within a bitmap, particularly for a new font immediately after conversion from a TTF font. But refont is easier to use in later years, and Font Patcher requires installation of Perl, while refont.exe is more drop and go.

== Comparison with Q3Font ==

For metric alteration, q3font has a native "*.fnt" human-readable format, and supports DAT <==> FNT conversions. For compatibility, so does refont.

=== Advantages of Q3Font ===

* This has been an important traditional tool for Doom3/TDM font manipulation.
* In addition to production/consumption of FNT, it -
** Allows creation of DAT & TGA files from a TrueType font (although for this purpose, [[ExportFontToDoom3]] has been preferred in practice).
** Can write (but not read) an alternative "compact report".

=== Advantages of Refont ===

* It's open-source, so further C++ development is possible.
* It has its own native human-readable format, "*.ref", similar to .fnt but better.
* The REF format can be read by [[datBounds]] to generate bitmap boundary & metrics visualizations.

The better features of REF are:

* Codepoints are enumerated in not just decimal, but also hex.
* Coordinates of the overall image box within its bitmap are expressed in pixel units, rather than [0...1] fractional floating point. So the user is spared having to manually do this tedious and error-prone calculation.
* This overcomes a drawback of FNT, that expresses the coordinates with only 6 digits after the decimal point, not quite enough to avoid minor mis-precisions.
* if optionally provided, a separate, read-only annotation file will automatically decorate the .ref file with helpful information as the file is generated. This is explained below.

Because the code is open-source, there's better clarity about -
* how parsing and calculations are done.
* what warnings are emitted.

Also, using "-stats", refont can write (but not read) an analysis of a DAT file, particularly looking for problematic/unimplemented Western-language characters.

== For Inspection & Correction of DAT files ==

''To Get the Data in Readable, Editable Form''

For viewing and altering in a text editor, two formats are provided. Both list every codepoint, in order from 0 to 255, as a block of data. Within each block, every item gets its own line.

=== As a FNT File ===

To create a q3font-compatable "<dat-name>.fnt" file:

refont -decompile <path to given .dat file> -fnt

where the path can be a full path, a relative path (e.g., starting with "./" or "../"), or just the file name in the current working directory. The resulting .fnt file will appear in the same directory. It have the same name as the .dat file, except for the extension. As a convenience to keep track of versions, it is not required that the file name be in the standard fontImage_nn.dat form.

Example code block for the letter A:
...
char 65
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
s 0.769531
t 0.250000
s2 0.847656
t2 0.320313
glyph 0
shaderName fonts/stone_0_24.tga
}
...

Note that Q3Font FNT expresses the s, t, s2, and t2 coordinates with only 6 digits after the decimal point, causing minor low-precision rounding during DAT --> FNT --> DAT roundtrips. For compatibility, Refont FNT does likewise.

=== As a REF File ===
''Starting with Refont v2.5, a mixture of 256x256 and 512x512 bitmap shaders, encountered with Carleton and Mason family fonts, can be handled. See further below.''

To create a refont-specific "<dat-name>.ref" file:

refont -decompile <path to given .dat file>

The same path and naming conventions as for .fnt generation discussed above apply here.

Example code block for the letter A when no supplemental annotation file is present (nor any per-line comments, e.g., with warnings):

...
char 65 (0x41)
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 197
coord_t 64
coord_s2 217
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

Items bolded differ from FNT format. The starting line expresses the value in hex. And rather than s, t, s2, t2 in fractional [0...1] floating point, the "coord_..." values are expressed (and editable) as integer coordinates of the bitmap, with a range reflecting bitmap size. The default TDM bitmap size is 256x256, but a few fonts use 512x512 and require special treatment discussed further below.

== When Editing ==
Refont has a minimal parser. To keep it happy, preserve the file's line structure. In particular:
* every REF and FNT file has the same number of lines. ''(Exception: REF may have additional starting lines to flag 512x512 bitmaps, discussed below. Generally, you won't edit these.)''
* all keywords within a block must be present, and in a particular order.
* each block must have exactly the same number of lines (except for the special one at the end).

The meaning of the font metrics are explained in [[Font_Metrics_%26_DAT_File_Format]]. The [[Q3Font]] article has an example of simple metric editing that is also pertinent to refont.

== To Move Changed FNT or REF Data Back to a DAT ==

refont -compile <path to given .fnt or .ref file>

This reverses the -decompile process, to create a .dat file whose name is derived from the .fnt or .ref file. Importantly, this decompile/compile cycle leaves .tga/.dds files untouched.

== The Annotation File ==
When told to generate a REF file (but not FNT), refont.exe also looks for a file called "refont_char_annotations.txt", in the same folder as refont.exe. That file should have exactly 256 data lines in it, one for each of the codepoints, in order. As the REF is generated, the line that starts a codepoint's data block gets the corresponding annotation line appended to it. Having the annotations come from an external file, instead of hard-coded into refont, allows required flexibility as to what information is presented. It even potentially allows refont to be used with other idTech3/4 games that don't necessarily used the TDM-specific codepoints. Also, the annotation files contain helpful specific comments (as lines that start with ";").

Each annotation:
* indicates what character symbol is ''expected''; it is oblivious as to what character if any is actually within the bounding box described by the DAT data.
* lives only in a REF file, and is not retained when converted to a DAT file. This also true for any manual supplementary annotations you might make.

This is clearer with examples. In 'Downloads' below are 4 different versions of "refont_char_annotations[...].txt". Three of these, specific to TDM's custom 'english' (i.e., composite European) codepage, are discussed here. To deploy, edit the filename of one of them to remove the square bracket text.

=== English with Symbol Only ===

This simple format is best for most purposes. The file entry for letter 'A' is just:

A

Then the block in a generated REF file would have that string appended, but with " // " inserted.
...
char 65 (0x41) // A
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 197
coord_t 64
coord_s2 217
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

=== English with Unicode-16 Codes and Names ===

This supplies the Unicode Consortium's official 16-bit codepoints (where U+NNNN = 0xNNNN) and their names, in the formal all-caps convention.

The file entry for letter 'A' is:

U+0041 LATIN CAPITAL LETTER A

Then the first line of the corresponding block in a generated REF file would show:
...
char 65 (0x41) // U+0041 LATIN CAPITAL LETTER A
...
Here's another example from that REF:
...
char 129 (0x81) // U+015A LATIN CAPITAL LETTER S WITH ACUTE
...
For control or TDM undefined characters, this annotation file assumes a hollow box glyph is the appropriate mapping:
...
char 0 (0x00) // U+24A1 WHITE SQUARE
...
But there are other choices, so edit the annotation file as you see fit.
=== English with 8859-x Source ===

This verbose format may be useful during font analysis. For letters that are in their expected locations as defined by ASCII or ISO 8859-1 (Latin-1) or Windows-1252 ("Western Europe"), the annotation is fairly minimal. Thus, letter 'A' has this:

0x41 is A

(TIP: If authoring your own annotation file, consider including a codepoint number on each line, like "0x41" here, to make the process easier.)

Then the first line of the corresponding block in a generated REF file would show:
...
char 65 (0x41) // 0x41 is A
...
Here are a few more interesting examples from that REF, with more expansive annotations:
...
char 5 (0x05) // 0x05 is a control character, unusable in TDM
...
char 166 (0xa6) // 0xA6 is Š (not ISO 8859-1 ¦) (from A9 in ISO 8859-2) (TDM only)
...

== Revising or Making Your Own Annotations File ==
If creating your own refont_char_annotations.txt file, note that encoding upper-range characters in UTF-8 will be more universal than using Windows region-specific codepages. To enter a UTF-8 character using its four digit hex Unicode (say, in a range of interest 0x0080-0x00FF):
* Under Windows, type the four hex digits followed by Alt-X.
* Under Linux, hold down Ctrl+Shift, type U followed by the 4 digits; release Ctrl+Shift.

When refont reads refont_char_annotations.txt, any line that starts with ";" will be ignored. The latter is so that you can put comments into the file, that will not propagate to the generated REF file. TIP: If such commenting is unwanted, start the line with <space> before ";".

Other than that, be sure to have exactly 256 lines of annotations (though refont will check and issue a warning if not). A line can be empty, i.e., have only the linebreak.

When generating a REF file, refont will automatically add " // " before each non-empty annotation, so don't include that.

== Adding Your Own Annotations to a REF File ==
Beyond the refont_char_annotation.txt content, you can add certain commentary to the REF file without it affecting its ability to convert to a DAT file. Here are the rules:
* Don't add or subtract lines, or comment out non-blank lines
* Feel free to append a comment to the end of a line, by beginning the comment with " //".
* Likewise, on a line starting with "char" that had an annotation automatically added, you can revise the annotation as you see fit.

Example with revision in bold:
...
char 65 (0x41) // '''Capital A was slightly clipped. Decremented s, s2 by 1. Looks OK now.'''
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 196 '''// WAS: 197'''
coord_t 64
coord_s2 216 '''// WAS: 217'''
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

In this way, you can markup a REF file as a record of work to do, work in progress, or work completed.

==Errors, Warnings, and Auto-Corrections==
''This covers the major overhaul of Refont v 2.1, and its added options -no_warn_comments and -scaling_ok.''

During the compile or decompile, errors and warnings may be generated in the console. Fatal errors are largely due to:
* file I/O problems;
* deviations from the strict DAT, REF, and FNT formats.

Warnings, which are not fatal, are largely due to anomolous numeric values. The TDM engine can tolerant some of these, so they don't necessarily need fixing.

===Fatal Errors when Parsing REF or FNT as Input===
A fatal error, due to divergence from the expected format while parsing, stops the program. While potentially due to many causes (e.g., adding or deleting lines), errors will be reported - with line number - as failures of:

''Variable Name Checks.'' The parser expects every variable name in a particular order. A mismatch happened.

''Integer Checks.'' Integer value was unparsable, or out of range for integer type. Checked for per-character variables height, top, bottom, pitch, xSkip, imageWidth, imageHeight, and glyph. Plus REF’s coord_s, coord_t, coord_s2, and coord_ t2.

''Float Checks.'' Floating point value was unparsable, or out of range for float type. Checked for glyphScale, and FNT’s per-character variables s, t, s2, t2.

===Post-Read MAJOR Warnings about REF, FNT, and DAT Input Values===
After parsing, the input process concludes with a separate loop of non-fatal warning analysis. Warnings during input, broadly categorized as major or minor, report to the console, but don’t do any value corrections (which is instead left to the subsequent file-write stage).

''For FNT’s and DAT’s s, t, s2, t2''
* Inexact Integer. The given bounding box value, expected in the range 0-1, when multiplied by 256.0 should be exactly an integer. If not, the divergence is likely due to miscalculation. (Actually, a divergence from an integer of under +/- 0.001 is tolerated by Refont and considered a minor warning, discussed below.)
* Float Out of Range 0.0 - 1.0. Or equivalently, post-multiplication, 0.0 - 256.0. (See the discussion of the edge cases under minor warnings below.)

''For Other Metrics of DAT, FNT, and REF''
* Integer Out of Range 0-256. For height, top, bottom, pitch, xSkip, imageWidth, imageHeight, and REF’s coord_s, coord_t, coord_s2, and coord_t2.
* Integer Non Zero. For glyph.
* Float Less Than Zero. For glyphScale (which is independent of a particular character).
* Inconsistent Metrics. For a given character, this compares two metrics and looks for inconsistencies. We’ll state this here in REF terms, e.g., using “coord_s” rather than “ROUND_TO_INT(s * 256.0f)”:
** imageHeight == height?
** imageWidth == coord_s2 - coord_s?
** imageHeight == coord_t2 - coord_t?

However, warnings about those last two "Inconsistent Metrics" criteria are suppressed if:
* you use refont's "-scaling_ok" option. This is helpful when there is extensive per-character scaling. (Only TDM’s mason and mason-glow use a lot of per-character scaling, specifically for all upper-case characters.)
* you have a 512x512 bitmap, where throughout, the imageWidth and imageHeight (and some other metrics) are expected to be scaled to "half" of the corresponding coord difference. As of refont 2.8, 1 pixel of wiggle-room is allowed for integer rounding. Only warnings will be issued that fail these checks:
** abs(imageWidth * 2 - (coord_s2 - coord_s)) > 1
** abs(imageHeight * 2 - (coord_t2 - coord_t)) > 1

===Post-Read MINOR Warnings for FNT’s and DAT’s s, t, s2, t2===
''Low Precision.'' This value, when multiplied by 256.0, should be exactly an integer. However, some generation or revision procedure (e.g., Q3Font’s DAT  FNT  DAT) may have not used sufficient precision to ensure this. An offset from an integer value of less than +/- 0.001 is considered a minor problem; otherwise, major as above.

This problem, when it occurs with a file, typically happens a lot. Consequently, it is not reported in an itemized way, but instead, the console will show total counts of affected characters and values.

Edge cases: a value of {s, s2, t, or t2} * 256.0 that is negative but closer to zero than -0.001000 is considered this type of minor problem (and is not considered out of range, which would be major). Likewise, if that value is greater than 256.000000, but less than 256.001000
===Automatic Corrections during Output to a REF File===
Certain problems, first detected during DAT input, are further addressed at write time. Because these problems were already reported to the console during the DAT read, nothing additional is written to console. Instead, there may be reporting within the REF file itself.

''Automatic Corrections.'' When writing a REF file, the integer values of coord_s, coord_t, coord_s2, and coord_t2 are calculated from DAT floats s, t, s2, and t2 respectively. A calculated coord_... value, if not already resulting in an integer, is automatically forced to the nearest integer. This is so whether it was earlier reported to the console as a Major or Minor Warning. (Before refont v 2.1, the REF might assign an unrounded decimal value; no longer true.)

''Warnings Not Automatically Corrected.'' Automatic fixing of other warnings is unwise and not offered. Why? Because the fix is not obvious or complex, and sometimes, the corresponding character glyph in the bitmap needs adjustment. This pertains to Major Warnings about:
* Integer values outside their expected range (e.g., 0-256), including post-rounding coord_... values.
* Inconsistent Metrics
===Generated Within-REF Comments during Output===
For most causes of a Major Warning during DAT read, during subsequent writing of the REF file, a similar comment is also generated within the REF, on the same line as the parameter assignment. For example:
char 95 (0x5f) // _
{
...
top -6 // WARNING: Not in range 0-256. Does bitmap or other metrics need adjusting?
...
}
...
char 140 (0x8c) // Ń
{
...
coord_t -10 // WARNING: Underlying DAT value -0.03906250, * 256.0 gave -10.000000000, not in range 0-256 once rounded. Does bitmap or other metrics need adjusting?
...
}
''Suppressing Comment Generation.'' Use the refont option “-no_warn_comments”. ''New to v 2.1.''

TIP: When editing a REF file with comments, you can keep them, change them, or delete them as you prefer. They have no impact on subsequent compiles to DAT.

''Coverage of Generated Within-REF Comments.'' A calculated value of coord_s, coord_t, coord_s2, or coord_t2 would have been flagged as a “Major Warning” during read if:
* the discrepancy from being an integer was non-trivial (+/- 0.001 or more), or
* the calculated and rounded integer is outside the range given by bitmap size, e.g., 0-256.

For these, a comment is generated. Other causes are:
* Integer Out of Range 0-256 ''(or 0-512 as applicable)''. For height, top, bottom, pitch, xSkip, imageWidth, imageHeight.
* Integer Non Zero. For glyph.
* Float Less Than Zero. For glyphScale (which is independent of a particular character).

''Major Warnings that Don’t Cause Within-REF Comments.'' Currently, this is limited to “Inconsistent Metrics”, which would probably require tagging on multiple lines.

== Special Handling of Fonts with 512x512 Bitmaps ==
Some DAT files reference bitmap shaders where some or all are of size 512x512, instead of the default 256x256. Refont v2.5+ can support this (replacing an insufficient first attempt in v2.4).

Font developers went to double-sized bitmaps to:
* in the case of Carleton, allow freehand drawing of missing European characters, which could be drawn more easily if twice standard size.
* in the case of Mason, have larger ASCII alphanumeric glyphs that would render with crisper edges.

In either case, the font characters when rendered in, say, the game main menu will be the same size as if from 256x256. This is because the imageWidth, imageHeight, height, and top metrics are not doubled.
In effect, a scaling by half (approximately, as constrained by integer values) is requested for all characters in the DAT file and applied by the engine.

=== When generating a REF file from a DAT file ===

refont -decompile <path to given .dat file> -512_<n> ''where <n> is a single digit, e.g. '1' in referenced shader name "font/Carleton_1_24.tga" ''

You should use multiple instances of the -512_<n> option, to cover all the 512x512 bitmaps found in the DAT file.

If ''all'' of a given DATs shaders are 512x512, you can use this shorter form:

refont -decompile <path to given .dat file> -512

Exercising -512... options will mean that in the generated REF file:

* There will be a one or more starting lines like:
# bitmap_<n>_size=512 ''(Refont will look for this if doing a subsequent compile to DAT)''
* If you specified the short form, it will expand to just the right number of starting lines.
* Values for coord_s, coord_s2, coord_t, and coord_t2 will have a normal range of 0-512 when appropriate. [COMING SOON: Those values may then be read properly by datBounds.].
* Any warnings expressed (within the file or within the command-line window) will be in terms of the correct range of values.
* Warning checks will expect a scaling by half for all characters. That is, while 512... requires scaling down by half, that scaling will not generate a warning (unless it's not EXACTLY by half, or within 1 pixel of that), so the -scaling_ok option is not needed just for the exactly-by-half scaling.

=== When generating a DAT file from a REF file ===

During refont -compile, no special command line options are needed. Instead, REF's starting lines of form "# bitmap_<n>_size=512" are inspected and coord ranges will be interpreted as 0-512 whenever appropriate.

=== Special Handling Recommendations for Carleton and Mason ===
''For fonts shipped with TDM 2.12 in tdm_fonts01.pk4. Illustrative command paths are shown; adjust to your working copy.''
==== Mason Family ====
The [[Mason Font]] uses within-DAT per-character scaling, as well as some but not all 512x512 bitmaps. Only 48pt Mason is shipped.

Because, under /dds/fonts/english/mason/, bitmaps masonalternate_0_48.dds to _2_ are 512x512, but _3_ to _5_ are not, use:

-decompile /fonts/english/mason/fontimage_48.dat -512_0 -512_1 -512_2 -scaling_ok

Because, under /dds/fonts/english/mason_glow/, bitmaps masonalternate_1_48.dds and _2_ are 512x512, but _0_ and _3_ to _5_ are not, use:

-decompile /fonts/english/mason_glow/fontimage_48.dat -512_1 -512_2 -scaling_ok

Russian versions use the default 256x256. [These possibly benefit from -scaling_ok; didn't investigate.]
==== Carleton Family ====
The 24pt size of carleton has two bitmaps under /dds/fonts/english/carleton/, namely carleton_0_24.dds and _1_, both of size 512x512. So use:

-decompile /fonts/english/carleton/fontimage_24.dat -512_0 -512_1
''or''
-decompile /fonts/english/carleton/fontimage_24.dat -512

The 24pt size of carleton_bold has bitmaps with identical content to carleton's, so use the same options:

-decompile /fonts/english/carleton_bold/fontimage_24.dat -512_0 -512_1
''or''
-decompile /fonts/english/carleton_bold/fontimage_24.dat -512

Other members of this family use the default 256x256 bitmaps:
* Sizes 12pt & 48pt
* carleton_condensed and carleton_glow. (Note: while helpful, it is not required that the base & glow have identical bitmap sizes.)
* Russian versions

==== These Fonts with Stats ====
With -stats discussed next, if reading a DAT file, you may use the -512... and scaling_ok options to be most correct, although neglecting to specify them will likely have no significant impact on the analytical results. If reading a REF file, the included "# bitmap_..." lines will take care of that for you.

== For Statistics on Unimplemented or Problematic Font Characters ==
DAT or (as of v2.3) REF file analysis here is primarily designed to benefit english/european fonts. It will use the optional annotation file if provided. Syntax:

refont -stats <path to given .dat or .ref file>

Use "-stats" by itself, not combined with "-compile" or "-decompile".

The resulting analysis report will have the same name and location as the input file, but with a ".txt" suffix.
The report provides categorized totals and (for problematic characters) itemizations across all 256 character codepoints.
The counts of problems should be considered minimums, since no inspection of bitmap files (TGA or DDS) is done.
But a perhaps surprising amount of insight can be gleaned just from DAT/REF file metrics.
Itemizations include annotations from the 'ref_char_annotation' file, if provided.

In the hunt for missing characters, 3 signatures are important:

* Presumed 'Hollow Box' = glyph's 'shadername' is <fontname>_0_<size>.dds only, and s & t are zero, but not s2 & t2
* '<Space>' = same test as 'Hollow Box', but pointed to by char 32 (0x20)
* 'Zero Box' = No glyph box (s, t, s2, t2 all zero)

A given analysis will assume either 'Hollow Box' or '<Space>' but not both.

The analysis provides totals and itemizations - grouped into lower (0-127) and upper ranges (128-255) - in several passes:

* Pass 1 - Handling of unprintable/unsupported/missing codepoints, indicated by Hollow Box, Zero Box, or <Space>. Some of these are not a problem, but some are tagged as "Undesirable".
* Pass 2 - Bad glyph box (negative s, t, s2, or t2; or s2 <= s, t2 <= t) or good glyph box with dubious metrics (imageHeight <= 0, imageWidth <=0, imageHeight != height). Excludes those already counted as "Undesirable" in Pass 1.
* Pass 3 - Detection of duplicate glyph boxes (other than Hollow Box, Zero Box, or <Space>). Detected by: glyph's values for shadername, s, t, s2, & t2 exactly match those of another codepoint. These are grouped into "Dup Sets".

Then, across passes 1-3, a count if given of the minimum "Total Glyphs Needing Work".

Refont version 2.3 adds additional passes:

* Pass 4 - Reports "Overlap Sets" rather than just "Dup Sets". A set here may include an unaccented "base character" that has been serving as a substitute work-around target for one or more missing accented characters. (What constitutes an "overlap" is idiosyncratic; see the source code for details.)
* Pass 5 - Same information as Pass 4, but sorted first by shader name (i.e., bitmap). Helpful for organizing bitmap-editing work.
* Pass 6 - An analysis focusing just on the planned migration of duplicate O/o-circumflex codepoints to G/g-cup glyphs.

== Downloads ==
Release 2.8 of March 19, 2026:
* [https://drive.google.com/file/d/1BHGkCOhgXP7bFp1mXyfgoRBUtqkbCVRb/view?usp=sharing refont.exe]
* [https://drive.google.com/file/d/1Cca_Xo3W5jYB_40RVo4aIPHAGIufA9V0/view?usp=sharing refont_source_v2.8.zip, with refont.cpp, refont.sln, open-source license]

Release 2.6 of July 28, 2025:
* [https://drive.google.com/file/d/1ABf4771Jr1C1hKbLx4xWq8lx8Kn7HdKP/view?usp=sharing refont.exe]
* [https://drive.google.com/file/d/1-k68eo0CHKZ-sM7JGP05axm49cc5De0T/view?usp=sharing source code: refont.cpp]

===Annotations===
''After download, to use any one of these, edit filename to remove "[...]" substring.''

Update of June 20, 2024. This reflects a change to the TDM charmap for 2.13, to replace duplicate O/o circumflex characters with G/g breve:

* refont_char_annotations[english with symbol only. With G-breve update].txt [https://drive.google.com/file/d/1rrt-O9DgD7Zn2Hxt7nBtViIlO4kv_gQB/view?usp=sharing here]. Recommended for most purposes with 'english' fonts.
* refont_char_annotations[english with Unicode-16 codes & names. With G-breve update].txt [https://drive.google.com/file/d/1AMxDKQc_DE33gsExiEkGp3x67eb4aGFh/view?usp=sharing here].
* refont_char_annotations[english with 8859-x source. With G-breve update].txt [https://drive.google.com/file/d/1xoeZ1poTbmkls-gE5PnbbMxdoz5KnMD7/view?usp=sharing].
* For Russian, see the previous update next.

Update of April 13, 2024:

* refont_char_annotations[english with symbol only].txt [https://drive.google.com/file/d/1ItM-aXps0xQE655HdaJM7Aje5lHewUfC/view?usp=sharing here]. Recommended for most purposes with 'english' fonts.
* refont_char_annotations[english with Unicode-16 codes and names].txt [https://drive.google.com/file/d/1gW7oO_wLqCEPSdm6b05OaTNYHnyuUSA-/view?usp=sharing here].
* refont_char_annotations[english with 8859-x source].txt [https://drive.google.com/file/d/1ZTcgA4QJYwXzNdqbolYkn0CCEDILD1bX/view?usp=sharing here]. Corrects and supersedes original english file.
* refont_char_annotations[russian].txt [https://drive.google.com/file/d/10txNXsSCtaTiT2iGT9o3iDxBU7HVYNxi/view?usp=sharing here]. Recommended for 'russian' fonts.

== For More ==
* See the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

Refont

2026-03-18T17:25:03Z

Geep: /* Special Handling of Fonts with 512x512 Bitmaps */ v2.8 adds 1-pixel slack, suppress warnings

''By Geep, 2024, and similar to the article about Q3Font.''

Introduced in 2024, the "refont" command-line utility allows inspection and alteration of [[Font Metrics & DAT File Format | font metrics]].
It is designed to be an easier-to-use version of the inspection/alteration functionalities of [[Q3Font]].
It also provides a font analysis feature.

== Comparison with Font Patcher ==

Refont can be seen as complementary to [[Font Patcher]]. The latter has additional features that may be better if planning a wholesale rearrangement or expansion of characters within a bitmap, particularly for a new font immediately after conversion from a TTF font. But refont is easier to use in later years, and Font Patcher requires installation of Perl, while refont.exe is more drop and go.

== Comparison with Q3Font ==

For metric alteration, q3font has a native "*.fnt" human-readable format, and supports DAT <==> FNT conversions. For compatibility, so does refont.

=== Advantages of Q3Font ===

* This has been an important traditional tool for Doom3/TDM font manipulation.
* In addition to production/consumption of FNT, it -
** Allows creation of DAT & TGA files from a TrueType font (although for this purpose, [[ExportFontToDoom3]] has been preferred in practice).
** Can write (but not read) an alternative "compact report".

=== Advantages of Refont ===

* It's open-source, so further C++ development is possible.
* It has its own native human-readable format, "*.ref", similar to .fnt but better.
* The REF format can be read by [[datBounds]] to generate bitmap boundary & metrics visualizations.

The better features of REF are:

* Codepoints are enumerated in not just decimal, but also hex.
* Coordinates of the overall image box within its bitmap are expressed in pixel units, rather than [0...1] fractional floating point. So the user is spared having to manually do this tedious and error-prone calculation.
* This overcomes a drawback of FNT, that expresses the coordinates with only 6 digits after the decimal point, not quite enough to avoid minor mis-precisions.
* if optionally provided, a separate, read-only annotation file will automatically decorate the .ref file with helpful information as the file is generated. This is explained below.

Because the code is open-source, there's better clarity about -
* how parsing and calculations are done.
* what warnings are emitted.

Also, using "-stats", refont can write (but not read) an analysis of a DAT file, particularly looking for problematic/unimplemented Western-language characters.

== For Inspection & Correction of DAT files ==

''To Get the Data in Readable, Editable Form''

For viewing and altering in a text editor, two formats are provided. Both list every codepoint, in order from 0 to 255, as a block of data. Within each block, every item gets its own line.

=== As a FNT File ===

To create a q3font-compatable "<dat-name>.fnt" file:

refont -decompile <path to given .dat file> -fnt

where the path can be a full path, a relative path (e.g., starting with "./" or "../"), or just the file name in the current working directory. The resulting .fnt file will appear in the same directory. It have the same name as the .dat file, except for the extension. As a convenience to keep track of versions, it is not required that the file name be in the standard fontImage_nn.dat form.

Example code block for the letter A:
...
char 65
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
s 0.769531
t 0.250000
s2 0.847656
t2 0.320313
glyph 0
shaderName fonts/stone_0_24.tga
}
...

Note that Q3Font FNT expresses the s, t, s2, and t2 coordinates with only 6 digits after the decimal point, causing minor low-precision rounding during DAT --> FNT --> DAT roundtrips. For compatibility, Refont FNT does likewise.

=== As a REF File ===
''Starting with Refont v2.5, a mixture of 256x256 and 512x512 bitmap shaders, encountered with Carleton and Mason family fonts, can be handled. See further below.''

To create a refont-specific "<dat-name>.ref" file:

refont -decompile <path to given .dat file>

The same path and naming conventions as for .fnt generation discussed above apply here.

Example code block for the letter A when no supplemental annotation file is present (nor any per-line comments, e.g., with warnings):

...
char 65 (0x41)
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 197
coord_t 64
coord_s2 217
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

Items bolded differ from FNT format. The starting line expresses the value in hex. And rather than s, t, s2, t2 in fractional [0...1] floating point, the "coord_..." values are expressed (and editable) as integer coordinates of the bitmap, with a range reflecting bitmap size. The default TDM bitmap size is 256x256, but a few fonts use 512x512 and require special treatment discussed further below.

== When Editing ==
Refont has a minimal parser. To keep it happy, preserve the file's line structure. In particular:
* every REF and FNT file has the same number of lines. ''(Exception: REF may have additional starting lines to flag 512x512 bitmaps, discussed below. Generally, you won't edit these.)''
* all keywords within a block must be present, and in a particular order.
* each block must have exactly the same number of lines (except for the special one at the end).

The meaning of the font metrics are explained in [[Font_Metrics_%26_DAT_File_Format]]. The [[Q3Font]] article has an example of simple metric editing that is also pertinent to refont.

== To Move Changed FNT or REF Data Back to a DAT ==

refont -compile <path to given .fnt or .ref file>

This reverses the -decompile process, to create a .dat file whose name is derived from the .fnt or .ref file. Importantly, this decompile/compile cycle leaves .tga/.dds files untouched.

== The Annotation File ==
When told to generate a REF file (but not FNT), refont.exe also looks for a file called "refont_char_annotations.txt", in the same folder as refont.exe. That file should have exactly 256 data lines in it, one for each of the codepoints, in order. As the REF is generated, the line that starts a codepoint's data block gets the corresponding annotation line appended to it. Having the annotations come from an external file, instead of hard-coded into refont, allows required flexibility as to what information is presented. It even potentially allows refont to be used with other idTech3/4 games that don't necessarily used the TDM-specific codepoints. Also, the annotation files contain helpful specific comments (as lines that start with ";").

Each annotation:
* indicates what character symbol is ''expected''; it is oblivious as to what character if any is actually within the bounding box described by the DAT data.
* lives only in a REF file, and is not retained when converted to a DAT file. This also true for any manual supplementary annotations you might make.

This is clearer with examples. In 'Downloads' below are 4 different versions of "refont_char_annotations[...].txt". Three of these, specific to TDM's custom 'english' (i.e., composite European) codepage, are discussed here. To deploy, edit the filename of one of them to remove the square bracket text.

=== English with Symbol Only ===

This simple format is best for most purposes. The file entry for letter 'A' is just:

A

Then the block in a generated REF file would have that string appended, but with " // " inserted.
...
char 65 (0x41) // A
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 197
coord_t 64
coord_s2 217
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

=== English with Unicode-16 Codes and Names ===

This supplies the Unicode Consortium's official 16-bit codepoints (where U+NNNN = 0xNNNN) and their names, in the formal all-caps convention.

The file entry for letter 'A' is:

U+0041 LATIN CAPITAL LETTER A

Then the first line of the corresponding block in a generated REF file would show:
...
char 65 (0x41) // U+0041 LATIN CAPITAL LETTER A
...
Here's another example from that REF:
...
char 129 (0x81) // U+015A LATIN CAPITAL LETTER S WITH ACUTE
...
For control or TDM undefined characters, this annotation file assumes a hollow box glyph is the appropriate mapping:
...
char 0 (0x00) // U+24A1 WHITE SQUARE
...
But there are other choices, so edit the annotation file as you see fit.
=== English with 8859-x Source ===

This verbose format may be useful during font analysis. For letters that are in their expected locations as defined by ASCII or ISO 8859-1 (Latin-1) or Windows-1252 ("Western Europe"), the annotation is fairly minimal. Thus, letter 'A' has this:

0x41 is A

(TIP: If authoring your own annotation file, consider including a codepoint number on each line, like "0x41" here, to make the process easier.)

Then the first line of the corresponding block in a generated REF file would show:
...
char 65 (0x41) // 0x41 is A
...
Here are a few more interesting examples from that REF, with more expansive annotations:
...
char 5 (0x05) // 0x05 is a control character, unusable in TDM
...
char 166 (0xa6) // 0xA6 is Š (not ISO 8859-1 ¦) (from A9 in ISO 8859-2) (TDM only)
...

== Revising or Making Your Own Annotations File ==
If creating your own refont_char_annotations.txt file, note that encoding upper-range characters in UTF-8 will be more universal than using Windows region-specific codepages. To enter a UTF-8 character using its four digit hex Unicode (say, in a range of interest 0x0080-0x00FF):
* Under Windows, type the four hex digits followed by Alt-X.
* Under Linux, hold down Ctrl+Shift, type U followed by the 4 digits; release Ctrl+Shift.

When refont reads refont_char_annotations.txt, any line that starts with ";" will be ignored. The latter is so that you can put comments into the file, that will not propagate to the generated REF file. TIP: If such commenting is unwanted, start the line with <space> before ";".

Other than that, be sure to have exactly 256 lines of annotations (though refont will check and issue a warning if not). A line can be empty, i.e., have only the linebreak.

When generating a REF file, refont will automatically add " // " before each non-empty annotation, so don't include that.

== Adding Your Own Annotations to a REF File ==
Beyond the refont_char_annotation.txt content, you can add certain commentary to the REF file without it affecting its ability to convert to a DAT file. Here are the rules:
* Don't add or subtract lines, or comment out non-blank lines
* Feel free to append a comment to the end of a line, by beginning the comment with " //".
* Likewise, on a line starting with "char" that had an annotation automatically added, you can revise the annotation as you see fit.

Example with revision in bold:
...
char 65 (0x41) // '''Capital A was slightly clipped. Decremented s, s2 by 1. Looks OK now.'''
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 196 '''// WAS: 197'''
coord_t 64
coord_s2 216 '''// WAS: 217'''
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

In this way, you can markup a REF file as a record of work to do, work in progress, or work completed.

==Errors, Warnings, and Auto-Corrections==
''This covers the major overhaul of Refont v 2.1, and its added options -no_warn_comments and -scaling_ok.''

During the compile or decompile, errors and warnings may be generated in the console. Fatal errors are largely due to:
* file I/O problems;
* deviations from the strict DAT, REF, and FNT formats.

Warnings, which are not fatal, are largely due to anomolous numeric values. The TDM engine can tolerant some of these, so they don't necessarily need fixing.

===Fatal Errors when Parsing REF or FNT as Input===
A fatal error, due to divergence from the expected format while parsing, stops the program. While potentially due to many causes (e.g., adding or deleting lines), errors will be reported - with line number - as failures of:

''Variable Name Checks.'' The parser expects every variable name in a particular order. A mismatch happened.

''Integer Checks.'' Integer value was unparsable, or out of range for integer type. Checked for per-character variables height, top, bottom, pitch, xSkip, imageWidth, imageHeight, and glyph. Plus REF’s coord_s, coord_t, coord_s2, and coord_ t2.

''Float Checks.'' Floating point value was unparsable, or out of range for float type. Checked for glyphScale, and FNT’s per-character variables s, t, s2, t2.

===Post-Read MAJOR Warnings about REF, FNT, and DAT Input Values===
After parsing, the input process concludes with a separate loop of non-fatal warning analysis. Warnings during input, broadly categorized as major or minor, report to the console, but don’t do any value corrections (which is instead left to the subsequent file-write stage).

''For FNT’s and DAT’s s, t, s2, t2''
* Inexact Integer. The given bounding box value, expected in the range 0-1, when multiplied by 256.0 should be exactly an integer. If not, the divergence is likely due to miscalculation. (Actually, a divergence from an integer of under +/- 0.001 is tolerated by Refont and considered a minor warning, discussed below.)
* Float Out of Range 0.0 - 1.0. Or equivalently, post-multiplication, 0.0 - 256.0. (See the discussion of the edge cases under minor warnings below.)

''For Other Metrics of DAT, FNT, and REF''
* Integer Out of Range 0-256. For height, top, bottom, pitch, xSkip, imageWidth, imageHeight, and REF’s coord_s, coord_t, coord_s2, and coord_t2.
* Integer Non Zero. For glyph.
* Float Less Than Zero. For glyphScale (which is independent of a particular character).
* Inconsistent Metrics. For a given character, this compares two metrics and looks for inconsistencies. We’ll state this here in REF terms, e.g., using “coord_s” rather than “ROUND_TO_INT(s * 256.0f)”:
** imageHeight == height?
** imageWidth == coord_s2 - coord_s?
** imageHeight == coord_t2 - coord_t?

However, warnings about those last two "Inconsistent Metrics" criteria are suppressed if:
* you use refont's "-scaling_ok" option. This is helpful when there is extensive per-character scaling. (Only TDM’s mason and mason-glow use a lot of per-character scaling, specifically for all upper-case characters.)
* you have a 512x512 bitmap, where throughout, the imageWidth and imageHeight (and some other metrics) are expected to be scaled to "half" of the corresponding coord difference. As of refont 2.8, 1 pixel of wiggle-room is allowed for integer rounding. Only warnings will be issued that fail these checks:
** abs(imageWidth * 2 - (coord_s2 - coord_s)) > 1
** abs(imageHeight * 2 - (coord_t2 - coord_t)) > 1

===Post-Read MINOR Warnings for FNT’s and DAT’s s, t, s2, t2===
''Low Precision.'' This value, when multiplied by 256.0, should be exactly an integer. However, some generation or revision procedure (e.g., Q3Font’s DAT  FNT  DAT) may have not used sufficient precision to ensure this. An offset from an integer value of less than +/- 0.001 is considered a minor problem; otherwise, major as above.

This problem, when it occurs with a file, typically happens a lot. Consequently, it is not reported in an itemized way, but instead, the console will show total counts of affected characters and values.

Edge cases: a value of {s, s2, t, or t2} * 256.0 that is negative but closer to zero than -0.001000 is considered this type of minor problem (and is not considered out of range, which would be major). Likewise, if that value is greater than 256.000000, but less than 256.001000
===Automatic Corrections during Output to a REF File===
Certain problems, first detected during DAT input, are further addressed at write time. Because these problems were already reported to the console during the DAT read, nothing additional is written to console. Instead, there may be reporting within the REF file itself.

''Automatic Corrections.'' When writing a REF file, the integer values of coord_s, coord_t, coord_s2, and coord_t2 are calculated from DAT floats s, t, s2, and t2 respectively. A calculated coord_... value, if not already resulting in an integer, is automatically forced to the nearest integer. This is so whether it was earlier reported to the console as a Major or Minor Warning. (Before refont v 2.1, the REF might assign an unrounded decimal value; no longer true.)

''Warnings Not Automatically Corrected.'' Automatic fixing of other warnings is unwise and not offered. Why? Because the fix is not obvious or complex, and sometimes, the corresponding character glyph in the bitmap needs adjustment. This pertains to Major Warnings about:
* Integer values outside their expected range (e.g., 0-256), including post-rounding coord_... values.
* Inconsistent Metrics
===Generated Within-REF Comments during Output===
For most causes of a Major Warning during DAT read, during subsequent writing of the REF file, a similar comment is also generated within the REF, on the same line as the parameter assignment. For example:
char 95 (0x5f) // _
{
...
top -6 // WARNING: Not in range 0-256. Does bitmap or other metrics need adjusting?
...
}
...
char 140 (0x8c) // Ń
{
...
coord_t -10 // WARNING: Underlying DAT value -0.03906250, * 256.0 gave -10.000000000, not in range 0-256 once rounded. Does bitmap or other metrics need adjusting?
...
}
''Suppressing Comment Generation.'' Use the refont option “-no_warn_comments”. ''New to v 2.1.''

TIP: When editing a REF file with comments, you can keep them, change them, or delete them as you prefer. They have no impact on subsequent compiles to DAT.

''Coverage of Generated Within-REF Comments.'' A calculated value of coord_s, coord_t, coord_s2, or coord_t2 would have been flagged as a “Major Warning” during read if:
* the discrepancy from being an integer was non-trivial (+/- 0.001 or more), or
* the calculated and rounded integer is outside the range given by bitmap size, e.g., 0-256.

For these, a comment is generated. Other causes are:
* Integer Out of Range 0-256 ''(or 0-512 as applicable)''. For height, top, bottom, pitch, xSkip, imageWidth, imageHeight.
* Integer Non Zero. For glyph.
* Float Less Than Zero. For glyphScale (which is independent of a particular character).

''Major Warnings that Don’t Cause Within-REF Comments.'' Currently, this is limited to “Inconsistent Metrics”, which would probably require tagging on multiple lines.

== Special Handling of Fonts with 512x512 Bitmaps ==
Some DAT files reference bitmap shaders where some or all are of size 512x512, instead of the default 256x256. Refont v2.5+ can support this (replacing an insufficient first attempt in v2.4).

Font developers went to double-sized bitmaps to:
* in the case of Carleton, allow freehand drawing of missing European characters, which could be drawn more easily if twice standard size.
* in the case of Mason, have larger ASCII alphanumeric glyphs that would render with crisper edges.

In either case, the font characters when rendered in, say, the game main menu will be the same size as if from 256x256. This is because the imageWidth, imageHeight, height, and top metrics are not doubled.
In effect, a scaling by half (approximately, as constrained by integer values) is requested for all characters in the DAT file and applied by the engine.

=== When generating a REF file from a DAT file ===

refont -decompile <path to given .dat file> -512_<n> ''where <n> is a single digit, e.g. '1' in referenced shader name "font/Carleton_1_24.tga" ''

You should use multiple instances of the -512_<n> option, to cover all the 512x512 bitmaps found in the DAT file.

If ''all'' of a given DATs shaders are 512x512, you can use this shorter form:

refont -decompile <path to given .dat file> -512

Exercising -512... options will mean that in the generated REF file:

* There will be a one or more starting lines like:
# bitmap_<n>_size=512 ''(Refont will look for this if doing a subsequent compile to DAT)''
* If you specified the short form, it will expand to just the right number of starting lines.
* Values for coord_s, coord_s2, coord_t, and coord_t2 will have a normal range of 0-512 when appropriate. [COMING SOON: Those values may then be read properly by datBounds.].
* Any warnings expressed (within the file or within the command-line window) will be in terms of the correct range of values.
* Warning checks will expect a scaling by half for all characters. That is, while 512... requires scaling down by half, that scaling will not generate a warning (unless it's not EXACTLY by half, or within 1 pixel of that), so the -scaling_ok option is not needed just for the exactly-by-half scaling.

=== When generating a DAT file from a REF file ===

During refont -compile, no special command line options are needed. Instead, REF's starting lines of form "# bitmap_<n>_size=512" are inspected and coord ranges will be interpreted as 0-512 whenever appropriate.

=== Special Handling Recommendations for Carleton and Mason ===
''For fonts shipped with TDM 2.12 in tdm_fonts01.pk4. Illustrative command paths are shown; adjust to your working copy.''
==== Mason Family ====
The [[Mason Font]] uses within-DAT per-character scaling, as well as some but not all 512x512 bitmaps. Only 48pt Mason is shipped.

Because, under /dds/fonts/english/mason/, bitmaps masonalternate_0_48.dds to _2_ are 512x512, but _3_ to _5_ are not, use:

-decompile /fonts/english/mason/fontimage_48.dat -512_0 -512_1 -512_2 -scaling_ok

Because, under /dds/fonts/english/mason_glow/, bitmaps masonalternate_1_48.dds and _2_ are 512x512, but _0_ and _3_ to _5_ are not, use:

-decompile /fonts/english/mason_glow/fontimage_48.dat -512_1 -512_2 -scaling_ok

Russian versions use the default 256x256. [These possibly benefit from -scaling_ok; didn't investigate.]
==== Carleton Family ====
The 24pt size of carleton has two bitmaps under /dds/fonts/english/carleton/, namely carleton_0_24.dds and _1_, both of size 512x512. So use:

-decompile /fonts/english/carleton/fontimage_24.dat -512_0 -512_1
''or''
-decompile /fonts/english/carleton/fontimage_24.dat -512

The 24pt size of carleton_bold has bitmaps with identical content to carleton's, so use the same options:

-decompile /fonts/english/carleton_bold/fontimage_24.dat -512_0 -512_1
''or''
-decompile /fonts/english/carleton_bold/fontimage_24.dat -512

Other members of this family use the default 256x256 bitmaps:
* Sizes 12pt & 48pt
* carleton_condensed and carleton_glow. (Note: while helpful, it is not required that the base & glow have identical bitmap sizes.)
* Russian versions

==== These Fonts with Stats ====
With -stats discussed next, if reading a DAT file, you may use the -512... and scaling_ok options to be most correct, although neglecting to specify them will likely have no significant impact on the analytical results. If reading a REF file, the included "# bitmap_..." lines will take care of that for you.

== For Statistics on Unimplemented or Problematic Font Characters ==
DAT or (as of v2.3) REF file analysis here is primarily designed to benefit english/european fonts. It will use the optional annotation file if provided. Syntax:

refont -stats <path to given .dat or .ref file>

Use "-stats" by itself, not combined with "-compile" or "-decompile".

The resulting analysis report will have the same name and location as the input file, but with a ".txt" suffix.
The report provides categorized totals and (for problematic characters) itemizations across all 256 character codepoints.
The counts of problems should be considered minimums, since no inspection of bitmap files (TGA or DDS) is done.
But a perhaps surprising amount of insight can be gleaned just from DAT/REF file metrics.
Itemizations include annotations from the 'ref_char_annotation' file, if provided.

In the hunt for missing characters, 3 signatures are important:

* Presumed 'Hollow Box' = glyph's 'shadername' is <fontname>_0_<size>.dds only, and s & t are zero, but not s2 & t2
* '<Space>' = same test as 'Hollow Box', but pointed to by char 32 (0x20)
* 'Zero Box' = No glyph box (s, t, s2, t2 all zero)

A given analysis will assume either 'Hollow Box' or '<Space>' but not both.

The analysis provides totals and itemizations - grouped into lower (0-127) and upper ranges (128-255) - in several passes:

* Pass 1 - Handling of unprintable/unsupported/missing codepoints, indicated by Hollow Box, Zero Box, or <Space>. Some of these are not a problem, but some are tagged as "Undesirable".
* Pass 2 - Bad glyph box (negative s, t, s2, or t2; or s2 <= s, t2 <= t) or good glyph box with dubious metrics (imageHeight <= 0, imageWidth <=0, imageHeight != height). Excludes those already counted as "Undesirable" in Pass 1.
* Pass 3 - Detection of duplicate glyph boxes (other than Hollow Box, Zero Box, or <Space>). Detected by: glyph's values for shadername, s, t, s2, & t2 exactly match those of another codepoint. These are grouped into "Dup Sets".

Then, across passes 1-3, a count if given of the minimum "Total Glyphs Needing Work".

Refont version 2.3 adds additional passes:

* Pass 4 - Reports "Overlap Sets" rather than just "Dup Sets". A set here may include an unaccented "base character" that has been serving as a substitute work-around target for one or more missing accented characters. (What constitutes an "overlap" is idiosyncratic; see the source code for details.)
* Pass 5 - Same information as Pass 4, but sorted first by shader name (i.e., bitmap). Helpful for organizing bitmap-editing work.
* Pass 6 - An analysis focusing just on the planned migration of duplicate O/o-circumflex codepoints to G/g-cup glyphs.

== Downloads ==
Release 2.6 of July 28, 2025:
* [https://drive.google.com/file/d/1ABf4771Jr1C1hKbLx4xWq8lx8Kn7HdKP/view?usp=sharing refont.exe]
* [https://drive.google.com/file/d/1-k68eo0CHKZ-sM7JGP05axm49cc5De0T/view?usp=sharing source code: refont.cpp]

===Annotations===
''After download, to use any one of these, edit filename to remove "[...]" substring.''

Update of June 20, 2024. This reflects a change to the TDM charmap for 2.13, to replace duplicate O/o circumflex characters with G/g breve:

* refont_char_annotations[english with symbol only. With G-breve update].txt [https://drive.google.com/file/d/1rrt-O9DgD7Zn2Hxt7nBtViIlO4kv_gQB/view?usp=sharing here]. Recommended for most purposes with 'english' fonts.
* refont_char_annotations[english with Unicode-16 codes & names. With G-breve update].txt [https://drive.google.com/file/d/1AMxDKQc_DE33gsExiEkGp3x67eb4aGFh/view?usp=sharing here].
* refont_char_annotations[english with 8859-x source. With G-breve update].txt [https://drive.google.com/file/d/1xoeZ1poTbmkls-gE5PnbbMxdoz5KnMD7/view?usp=sharing].
* For Russian, see the previous update next.

Update of April 13, 2024:

* refont_char_annotations[english with symbol only].txt [https://drive.google.com/file/d/1ItM-aXps0xQE655HdaJM7Aje5lHewUfC/view?usp=sharing here]. Recommended for most purposes with 'english' fonts.
* refont_char_annotations[english with Unicode-16 codes and names].txt [https://drive.google.com/file/d/1gW7oO_wLqCEPSdm6b05OaTNYHnyuUSA-/view?usp=sharing here].
* refont_char_annotations[english with 8859-x source].txt [https://drive.google.com/file/d/1ZTcgA4QJYwXzNdqbolYkn0CCEDILD1bX/view?usp=sharing here]. Corrects and supersedes original english file.
* refont_char_annotations[russian].txt [https://drive.google.com/file/d/10txNXsSCtaTiT2iGT9o3iDxBU7HVYNxi/view?usp=sharing here]. Recommended for 'russian' fonts.

== For More ==
* See the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

Refont

2026-03-18T17:18:00Z

Geep: /* Post-Read MAJOR Warnings about REF, FNT, and DAT Input Values */

''By Geep, 2024, and similar to the article about Q3Font.''

Introduced in 2024, the "refont" command-line utility allows inspection and alteration of [[Font Metrics & DAT File Format | font metrics]].
It is designed to be an easier-to-use version of the inspection/alteration functionalities of [[Q3Font]].
It also provides a font analysis feature.

== Comparison with Font Patcher ==

Refont can be seen as complementary to [[Font Patcher]]. The latter has additional features that may be better if planning a wholesale rearrangement or expansion of characters within a bitmap, particularly for a new font immediately after conversion from a TTF font. But refont is easier to use in later years, and Font Patcher requires installation of Perl, while refont.exe is more drop and go.

== Comparison with Q3Font ==

For metric alteration, q3font has a native "*.fnt" human-readable format, and supports DAT <==> FNT conversions. For compatibility, so does refont.

=== Advantages of Q3Font ===

* This has been an important traditional tool for Doom3/TDM font manipulation.
* In addition to production/consumption of FNT, it -
** Allows creation of DAT & TGA files from a TrueType font (although for this purpose, [[ExportFontToDoom3]] has been preferred in practice).
** Can write (but not read) an alternative "compact report".

=== Advantages of Refont ===

* It's open-source, so further C++ development is possible.
* It has its own native human-readable format, "*.ref", similar to .fnt but better.
* The REF format can be read by [[datBounds]] to generate bitmap boundary & metrics visualizations.

The better features of REF are:

* Codepoints are enumerated in not just decimal, but also hex.
* Coordinates of the overall image box within its bitmap are expressed in pixel units, rather than [0...1] fractional floating point. So the user is spared having to manually do this tedious and error-prone calculation.
* This overcomes a drawback of FNT, that expresses the coordinates with only 6 digits after the decimal point, not quite enough to avoid minor mis-precisions.
* if optionally provided, a separate, read-only annotation file will automatically decorate the .ref file with helpful information as the file is generated. This is explained below.

Because the code is open-source, there's better clarity about -
* how parsing and calculations are done.
* what warnings are emitted.

Also, using "-stats", refont can write (but not read) an analysis of a DAT file, particularly looking for problematic/unimplemented Western-language characters.

== For Inspection & Correction of DAT files ==

''To Get the Data in Readable, Editable Form''

For viewing and altering in a text editor, two formats are provided. Both list every codepoint, in order from 0 to 255, as a block of data. Within each block, every item gets its own line.

=== As a FNT File ===

To create a q3font-compatable "<dat-name>.fnt" file:

refont -decompile <path to given .dat file> -fnt

where the path can be a full path, a relative path (e.g., starting with "./" or "../"), or just the file name in the current working directory. The resulting .fnt file will appear in the same directory. It have the same name as the .dat file, except for the extension. As a convenience to keep track of versions, it is not required that the file name be in the standard fontImage_nn.dat form.

Example code block for the letter A:
...
char 65
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
s 0.769531
t 0.250000
s2 0.847656
t2 0.320313
glyph 0
shaderName fonts/stone_0_24.tga
}
...

Note that Q3Font FNT expresses the s, t, s2, and t2 coordinates with only 6 digits after the decimal point, causing minor low-precision rounding during DAT --> FNT --> DAT roundtrips. For compatibility, Refont FNT does likewise.

=== As a REF File ===
''Starting with Refont v2.5, a mixture of 256x256 and 512x512 bitmap shaders, encountered with Carleton and Mason family fonts, can be handled. See further below.''

To create a refont-specific "<dat-name>.ref" file:

refont -decompile <path to given .dat file>

The same path and naming conventions as for .fnt generation discussed above apply here.

Example code block for the letter A when no supplemental annotation file is present (nor any per-line comments, e.g., with warnings):

...
char 65 (0x41)
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 197
coord_t 64
coord_s2 217
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

Items bolded differ from FNT format. The starting line expresses the value in hex. And rather than s, t, s2, t2 in fractional [0...1] floating point, the "coord_..." values are expressed (and editable) as integer coordinates of the bitmap, with a range reflecting bitmap size. The default TDM bitmap size is 256x256, but a few fonts use 512x512 and require special treatment discussed further below.

== When Editing ==
Refont has a minimal parser. To keep it happy, preserve the file's line structure. In particular:
* every REF and FNT file has the same number of lines. ''(Exception: REF may have additional starting lines to flag 512x512 bitmaps, discussed below. Generally, you won't edit these.)''
* all keywords within a block must be present, and in a particular order.
* each block must have exactly the same number of lines (except for the special one at the end).

The meaning of the font metrics are explained in [[Font_Metrics_%26_DAT_File_Format]]. The [[Q3Font]] article has an example of simple metric editing that is also pertinent to refont.

== To Move Changed FNT or REF Data Back to a DAT ==

refont -compile <path to given .fnt or .ref file>

This reverses the -decompile process, to create a .dat file whose name is derived from the .fnt or .ref file. Importantly, this decompile/compile cycle leaves .tga/.dds files untouched.

== The Annotation File ==
When told to generate a REF file (but not FNT), refont.exe also looks for a file called "refont_char_annotations.txt", in the same folder as refont.exe. That file should have exactly 256 data lines in it, one for each of the codepoints, in order. As the REF is generated, the line that starts a codepoint's data block gets the corresponding annotation line appended to it. Having the annotations come from an external file, instead of hard-coded into refont, allows required flexibility as to what information is presented. It even potentially allows refont to be used with other idTech3/4 games that don't necessarily used the TDM-specific codepoints. Also, the annotation files contain helpful specific comments (as lines that start with ";").

Each annotation:
* indicates what character symbol is ''expected''; it is oblivious as to what character if any is actually within the bounding box described by the DAT data.
* lives only in a REF file, and is not retained when converted to a DAT file. This also true for any manual supplementary annotations you might make.

This is clearer with examples. In 'Downloads' below are 4 different versions of "refont_char_annotations[...].txt". Three of these, specific to TDM's custom 'english' (i.e., composite European) codepage, are discussed here. To deploy, edit the filename of one of them to remove the square bracket text.

=== English with Symbol Only ===

This simple format is best for most purposes. The file entry for letter 'A' is just:

A

Then the block in a generated REF file would have that string appended, but with " // " inserted.
...
char 65 (0x41) // A
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 197
coord_t 64
coord_s2 217
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

=== English with Unicode-16 Codes and Names ===

This supplies the Unicode Consortium's official 16-bit codepoints (where U+NNNN = 0xNNNN) and their names, in the formal all-caps convention.

The file entry for letter 'A' is:

U+0041 LATIN CAPITAL LETTER A

Then the first line of the corresponding block in a generated REF file would show:
...
char 65 (0x41) // U+0041 LATIN CAPITAL LETTER A
...
Here's another example from that REF:
...
char 129 (0x81) // U+015A LATIN CAPITAL LETTER S WITH ACUTE
...
For control or TDM undefined characters, this annotation file assumes a hollow box glyph is the appropriate mapping:
...
char 0 (0x00) // U+24A1 WHITE SQUARE
...
But there are other choices, so edit the annotation file as you see fit.
=== English with 8859-x Source ===

This verbose format may be useful during font analysis. For letters that are in their expected locations as defined by ASCII or ISO 8859-1 (Latin-1) or Windows-1252 ("Western Europe"), the annotation is fairly minimal. Thus, letter 'A' has this:

0x41 is A

(TIP: If authoring your own annotation file, consider including a codepoint number on each line, like "0x41" here, to make the process easier.)

Then the first line of the corresponding block in a generated REF file would show:
...
char 65 (0x41) // 0x41 is A
...
Here are a few more interesting examples from that REF, with more expansive annotations:
...
char 5 (0x05) // 0x05 is a control character, unusable in TDM
...
char 166 (0xa6) // 0xA6 is Š (not ISO 8859-1 ¦) (from A9 in ISO 8859-2) (TDM only)
...

== Revising or Making Your Own Annotations File ==
If creating your own refont_char_annotations.txt file, note that encoding upper-range characters in UTF-8 will be more universal than using Windows region-specific codepages. To enter a UTF-8 character using its four digit hex Unicode (say, in a range of interest 0x0080-0x00FF):
* Under Windows, type the four hex digits followed by Alt-X.
* Under Linux, hold down Ctrl+Shift, type U followed by the 4 digits; release Ctrl+Shift.

When refont reads refont_char_annotations.txt, any line that starts with ";" will be ignored. The latter is so that you can put comments into the file, that will not propagate to the generated REF file. TIP: If such commenting is unwanted, start the line with <space> before ";".

Other than that, be sure to have exactly 256 lines of annotations (though refont will check and issue a warning if not). A line can be empty, i.e., have only the linebreak.

When generating a REF file, refont will automatically add " // " before each non-empty annotation, so don't include that.

== Adding Your Own Annotations to a REF File ==
Beyond the refont_char_annotation.txt content, you can add certain commentary to the REF file without it affecting its ability to convert to a DAT file. Here are the rules:
* Don't add or subtract lines, or comment out non-blank lines
* Feel free to append a comment to the end of a line, by beginning the comment with " //".
* Likewise, on a line starting with "char" that had an annotation automatically added, you can revise the annotation as you see fit.

Example with revision in bold:
...
char 65 (0x41) // '''Capital A was slightly clipped. Decremented s, s2 by 1. Looks OK now.'''
{
height 18
top 18
bottom 0
pitch 3
xSkip 18
imageWidth 20
imageHeight 18
coord_s 196 '''// WAS: 197'''
coord_t 64
coord_s2 216 '''// WAS: 217'''
coord_t2 82
glyph 0
shaderName fonts/stone_0_24.tga
}
...

In this way, you can markup a REF file as a record of work to do, work in progress, or work completed.

==Errors, Warnings, and Auto-Corrections==
''This covers the major overhaul of Refont v 2.1, and its added options -no_warn_comments and -scaling_ok.''

During the compile or decompile, errors and warnings may be generated in the console. Fatal errors are largely due to:
* file I/O problems;
* deviations from the strict DAT, REF, and FNT formats.

Warnings, which are not fatal, are largely due to anomolous numeric values. The TDM engine can tolerant some of these, so they don't necessarily need fixing.

===Fatal Errors when Parsing REF or FNT as Input===
A fatal error, due to divergence from the expected format while parsing, stops the program. While potentially due to many causes (e.g., adding or deleting lines), errors will be reported - with line number - as failures of:

''Variable Name Checks.'' The parser expects every variable name in a particular order. A mismatch happened.

''Integer Checks.'' Integer value was unparsable, or out of range for integer type. Checked for per-character variables height, top, bottom, pitch, xSkip, imageWidth, imageHeight, and glyph. Plus REF’s coord_s, coord_t, coord_s2, and coord_ t2.

''Float Checks.'' Floating point value was unparsable, or out of range for float type. Checked for glyphScale, and FNT’s per-character variables s, t, s2, t2.

===Post-Read MAJOR Warnings about REF, FNT, and DAT Input Values===
After parsing, the input process concludes with a separate loop of non-fatal warning analysis. Warnings during input, broadly categorized as major or minor, report to the console, but don’t do any value corrections (which is instead left to the subsequent file-write stage).

''For FNT’s and DAT’s s, t, s2, t2''
* Inexact Integer. The given bounding box value, expected in the range 0-1, when multiplied by 256.0 should be exactly an integer. If not, the divergence is likely due to miscalculation. (Actually, a divergence from an integer of under +/- 0.001 is tolerated by Refont and considered a minor warning, discussed below.)
* Float Out of Range 0.0 - 1.0. Or equivalently, post-multiplication, 0.0 - 256.0. (See the discussion of the edge cases under minor warnings below.)

''For Other Metrics of DAT, FNT, and REF''
* Integer Out of Range 0-256. For height, top, bottom, pitch, xSkip, imageWidth, imageHeight, and REF’s coord_s, coord_t, coord_s2, and coord_t2.
* Integer Non Zero. For glyph.
* Float Less Than Zero. For glyphScale (which is independent of a particular character).
* Inconsistent Metrics. For a given character, this compares two metrics and looks for inconsistencies. We’ll state this here in REF terms, e.g., using “coord_s” rather than “ROUND_TO_INT(s * 256.0f)”:
** imageHeight == height?
** imageWidth == coord_s2 - coord_s?
** imageHeight == coord_t2 - coord_t?

However, warnings about those last two "Inconsistent Metrics" criteria are suppressed if:
* you use refont's "-scaling_ok" option. This is helpful when there is extensive per-character scaling. (Only TDM’s mason and mason-glow use a lot of per-character scaling, specifically for all upper-case characters.)
* you have a 512x512 bitmap, where throughout, the imageWidth and imageHeight (and some other metrics) are expected to be scaled to "half" of the corresponding coord difference. As of refont 2.8, 1 pixel of wiggle-room is allowed for integer rounding. Only warnings will be issued that fail these checks:
** abs(imageWidth * 2 - (coord_s2 - coord_s)) > 1
** abs(imageHeight * 2 - (coord_t2 - coord_t)) > 1

===Post-Read MINOR Warnings for FNT’s and DAT’s s, t, s2, t2===
''Low Precision.'' This value, when multiplied by 256.0, should be exactly an integer. However, some generation or revision procedure (e.g., Q3Font’s DAT  FNT  DAT) may have not used sufficient precision to ensure this. An offset from an integer value of less than +/- 0.001 is considered a minor problem; otherwise, major as above.

This problem, when it occurs with a file, typically happens a lot. Consequently, it is not reported in an itemized way, but instead, the console will show total counts of affected characters and values.

Edge cases: a value of {s, s2, t, or t2} * 256.0 that is negative but closer to zero than -0.001000 is considered this type of minor problem (and is not considered out of range, which would be major). Likewise, if that value is greater than 256.000000, but less than 256.001000
===Automatic Corrections during Output to a REF File===
Certain problems, first detected during DAT input, are further addressed at write time. Because these problems were already reported to the console during the DAT read, nothing additional is written to console. Instead, there may be reporting within the REF file itself.

''Automatic Corrections.'' When writing a REF file, the integer values of coord_s, coord_t, coord_s2, and coord_t2 are calculated from DAT floats s, t, s2, and t2 respectively. A calculated coord_... value, if not already resulting in an integer, is automatically forced to the nearest integer. This is so whether it was earlier reported to the console as a Major or Minor Warning. (Before refont v 2.1, the REF might assign an unrounded decimal value; no longer true.)

''Warnings Not Automatically Corrected.'' Automatic fixing of other warnings is unwise and not offered. Why? Because the fix is not obvious or complex, and sometimes, the corresponding character glyph in the bitmap needs adjustment. This pertains to Major Warnings about:
* Integer values outside their expected range (e.g., 0-256), including post-rounding coord_... values.
* Inconsistent Metrics
===Generated Within-REF Comments during Output===
For most causes of a Major Warning during DAT read, during subsequent writing of the REF file, a similar comment is also generated within the REF, on the same line as the parameter assignment. For example:
char 95 (0x5f) // _
{
...
top -6 // WARNING: Not in range 0-256. Does bitmap or other metrics need adjusting?
...
}
...
char 140 (0x8c) // Ń
{
...
coord_t -10 // WARNING: Underlying DAT value -0.03906250, * 256.0 gave -10.000000000, not in range 0-256 once rounded. Does bitmap or other metrics need adjusting?
...
}
''Suppressing Comment Generation.'' Use the refont option “-no_warn_comments”. ''New to v 2.1.''

TIP: When editing a REF file with comments, you can keep them, change them, or delete them as you prefer. They have no impact on subsequent compiles to DAT.

''Coverage of Generated Within-REF Comments.'' A calculated value of coord_s, coord_t, coord_s2, or coord_t2 would have been flagged as a “Major Warning” during read if:
* the discrepancy from being an integer was non-trivial (+/- 0.001 or more), or
* the calculated and rounded integer is outside the range given by bitmap size, e.g., 0-256.

For these, a comment is generated. Other causes are:
* Integer Out of Range 0-256 ''(or 0-512 as applicable)''. For height, top, bottom, pitch, xSkip, imageWidth, imageHeight.
* Integer Non Zero. For glyph.
* Float Less Than Zero. For glyphScale (which is independent of a particular character).

''Major Warnings that Don’t Cause Within-REF Comments.'' Currently, this is limited to “Inconsistent Metrics”, which would probably require tagging on multiple lines.

== Special Handling of Fonts with 512x512 Bitmaps ==
Some DAT files reference bitmap shaders where some or all are of size 512x512, instead of the default 256x256. Refont v2.5+ can support this (replacing an insufficient first attempt in v2.4).

Font developers went to double-sized bitmaps to:
* in the case of Carleton, allow freehand drawing of missing European characters, which could be drawn more easily if twice standard size.
* in the case of Mason, have larger ASCII alphanumeric glyphs that would render with crisper edges.

In either case, the font characters when rendered in, say, the game main menu will be the same size as if from 256x256. This is because the imageWidth and imageHeight metrics are not doubled.
In effect, a scaling by half is requested for all characters in the DAT file and applied by the engine.

=== When generating a REF file from a DAT file ===

refont -decompile <path to given .dat file> -512_<n> ''where <n> is a single digit, e.g. '1' in referenced shader name "font/Carleton_1_24.tga" ''

You should use multiple instances of the -512_<n> option, to cover all the 512x512 bitmaps found in the DAT file.

If ''all'' of a given DATs shaders are 512x512, you can use this shorter form:

refont -decompile <path to given .dat file> -512

Exercising -512... options will mean that in the generated REF file:

* There will be a one or more starting lines like:
# bitmap_<n>_size=512 ''(Refont will look for this if doing a subsequent compile to DAT)''
* If you specified the short form, it will expand to just the right number of starting lines.
* Values for coord_s, coord_s2, coord_t, and coord_t2 will have a normal range of 0-512 when appropriate. [COMING SOON: Those values may then be read properly by datBounds.].
* Any warnings expressed (within the file or within the command-line window) will be in terms of the correct range of values.
* Warning checks will expect a scaling by half for all characters. That is, while 512... requires scaling down by half, that scaling will not generate a warning (unless it's not EXACTLY by half), so the -scaling_ok option is not needed just for the exactly-by-half scaling.

=== When generating a DAT file from a REF file ===

During refont -compile, no special command line options are needed. Instead, REF's starting lines of form "# bitmap_<n>_size=512" are inspected and coord ranges will be interpreted as 0-512 whenever appropriate.

=== Special Handling Recommendations for Carleton and Mason ===
''For fonts shipped with TDM 2.12 in tdm_fonts01.pk4. Illustrative command paths are shown; adjust to your working copy.''
==== Mason Family ====
The [[Mason Font]] uses within-DAT per-character scaling, as well as some but not all 512x512 bitmaps. Only 48pt Mason is shipped.

Because, under /dds/fonts/english/mason/, bitmaps masonalternate_0_48.dds to _2_ are 512x512, but _3_ to _5_ are not, use:

-decompile /fonts/english/mason/fontimage_48.dat -512_0 -512_1 -512_2 -scaling_ok

Because, under /dds/fonts/english/mason_glow/, bitmaps masonalternate_1_48.dds and _2_ are 512x512, but _0_ and _3_ to _5_ are not, use:

-decompile /fonts/english/mason_glow/fontimage_48.dat -512_1 -512_2 -scaling_ok

Russian versions use the default 256x256. [These possibly benefit from -scaling_ok; didn't investigate.]
==== Carleton Family ====
The 24pt size of carleton has two bitmaps under /dds/fonts/english/carleton/, namely carleton_0_24.dds and _1_, both of size 512x512. So use:

-decompile /fonts/english/carleton/fontimage_24.dat -512_0 -512_1
''or''
-decompile /fonts/english/carleton/fontimage_24.dat -512

The 24pt size of carleton_bold has bitmaps with identical content to carleton's, so use the same options:

-decompile /fonts/english/carleton_bold/fontimage_24.dat -512_0 -512_1
''or''
-decompile /fonts/english/carleton_bold/fontimage_24.dat -512

Other members of this family use the default 256x256 bitmaps:
* Sizes 12pt & 48pt
* carleton_condensed and carleton_glow. (Note: while helpful, it is not required that the base & glow have identical bitmap sizes.)
* Russian versions

==== These Fonts with Stats ====
With -stats discussed next, if reading a DAT file, you may use the -512... and scaling_ok options to be most correct, although neglecting to specify them will likely have no significant impact on the analytical results. If reading a REF file, the included "# bitmap_..." lines will take care of that for you.

== For Statistics on Unimplemented or Problematic Font Characters ==
DAT or (as of v2.3) REF file analysis here is primarily designed to benefit english/european fonts. It will use the optional annotation file if provided. Syntax:

refont -stats <path to given .dat or .ref file>

Use "-stats" by itself, not combined with "-compile" or "-decompile".

The resulting analysis report will have the same name and location as the input file, but with a ".txt" suffix.
The report provides categorized totals and (for problematic characters) itemizations across all 256 character codepoints.
The counts of problems should be considered minimums, since no inspection of bitmap files (TGA or DDS) is done.
But a perhaps surprising amount of insight can be gleaned just from DAT/REF file metrics.
Itemizations include annotations from the 'ref_char_annotation' file, if provided.

In the hunt for missing characters, 3 signatures are important:

* Presumed 'Hollow Box' = glyph's 'shadername' is <fontname>_0_<size>.dds only, and s & t are zero, but not s2 & t2
* '<Space>' = same test as 'Hollow Box', but pointed to by char 32 (0x20)
* 'Zero Box' = No glyph box (s, t, s2, t2 all zero)

A given analysis will assume either 'Hollow Box' or '<Space>' but not both.

The analysis provides totals and itemizations - grouped into lower (0-127) and upper ranges (128-255) - in several passes:

* Pass 1 - Handling of unprintable/unsupported/missing codepoints, indicated by Hollow Box, Zero Box, or <Space>. Some of these are not a problem, but some are tagged as "Undesirable".
* Pass 2 - Bad glyph box (negative s, t, s2, or t2; or s2 <= s, t2 <= t) or good glyph box with dubious metrics (imageHeight <= 0, imageWidth <=0, imageHeight != height). Excludes those already counted as "Undesirable" in Pass 1.
* Pass 3 - Detection of duplicate glyph boxes (other than Hollow Box, Zero Box, or <Space>). Detected by: glyph's values for shadername, s, t, s2, & t2 exactly match those of another codepoint. These are grouped into "Dup Sets".

Then, across passes 1-3, a count if given of the minimum "Total Glyphs Needing Work".

Refont version 2.3 adds additional passes:

* Pass 4 - Reports "Overlap Sets" rather than just "Dup Sets". A set here may include an unaccented "base character" that has been serving as a substitute work-around target for one or more missing accented characters. (What constitutes an "overlap" is idiosyncratic; see the source code for details.)
* Pass 5 - Same information as Pass 4, but sorted first by shader name (i.e., bitmap). Helpful for organizing bitmap-editing work.
* Pass 6 - An analysis focusing just on the planned migration of duplicate O/o-circumflex codepoints to G/g-cup glyphs.

== Downloads ==
Release 2.6 of July 28, 2025:
* [https://drive.google.com/file/d/1ABf4771Jr1C1hKbLx4xWq8lx8Kn7HdKP/view?usp=sharing refont.exe]
* [https://drive.google.com/file/d/1-k68eo0CHKZ-sM7JGP05axm49cc5De0T/view?usp=sharing source code: refont.cpp]

===Annotations===
''After download, to use any one of these, edit filename to remove "[...]" substring.''

Update of June 20, 2024. This reflects a change to the TDM charmap for 2.13, to replace duplicate O/o circumflex characters with G/g breve:

* refont_char_annotations[english with symbol only. With G-breve update].txt [https://drive.google.com/file/d/1rrt-O9DgD7Zn2Hxt7nBtViIlO4kv_gQB/view?usp=sharing here]. Recommended for most purposes with 'english' fonts.
* refont_char_annotations[english with Unicode-16 codes & names. With G-breve update].txt [https://drive.google.com/file/d/1AMxDKQc_DE33gsExiEkGp3x67eb4aGFh/view?usp=sharing here].
* refont_char_annotations[english with 8859-x source. With G-breve update].txt [https://drive.google.com/file/d/1xoeZ1poTbmkls-gE5PnbbMxdoz5KnMD7/view?usp=sharing].
* For Russian, see the previous update next.

Update of April 13, 2024:

* refont_char_annotations[english with symbol only].txt [https://drive.google.com/file/d/1ItM-aXps0xQE655HdaJM7Aje5lHewUfC/view?usp=sharing here]. Recommended for most purposes with 'english' fonts.
* refont_char_annotations[english with Unicode-16 codes and names].txt [https://drive.google.com/file/d/1gW7oO_wLqCEPSdm6b05OaTNYHnyuUSA-/view?usp=sharing here].
* refont_char_annotations[english with 8859-x source].txt [https://drive.google.com/file/d/1ZTcgA4QJYwXzNdqbolYkn0CCEDILD1bX/view?usp=sharing here]. Corrects and supersedes original english file.
* refont_char_annotations[russian].txt [https://drive.google.com/file/d/10txNXsSCtaTiT2iGT9o3iDxBU7HVYNxi/view?usp=sharing here]. Recommended for 'russian' fonts.

== For More ==
* See the [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ summary analysis of 2.12 TDM fonts], based on applying 'refont -stats ...' to all 'english' DAT files.

{{tutorial}} [[Category:Fonts]]

ExportUnicodeFontToDoom3

2026-03-16T20:40:25Z

Geep: /* unicodeMap */ Must keep file ordered

''By Geep, 2025''

== Introduction ==

In 2025, kalinovka in [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization Font localization] sought to extend TDM’s Mason 48pt font, used in the main menu, to include missing Cyrillic glyphs. This would allow this font to be used in an FM and still support a Russian translation.

This offshoot of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256] is a generalized response to that. The main idea to select an input TTF font that includes not just ASCII or ANSI, but offers additional Unicode characters, like Cyrillic. The program still limits output to a maximum of 256 characters, consistent with the DAT format.

To achieve this, it reads in an external human-readable "unicodeMap" file, in Unicode.org’s "Format A". This format provides a mapping from the traditional 8-bit encoding that TDM uses to the corresponding UCS (Unicode 16-bit) value. Unicode.org provides stock files for standard ISO and Windows 8-bit encodings. Of specific interest here is [https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT cp1251.txt for Cyrillic]. This requires just trivial editing for [https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset TDM-specific codepoints]. As discussed below, you can further edit a unicodeMap file in advance, if you want to generate just a subset of glyphs.

More broadly, this program supersedes ExportFontToDoom3 and ExportFontToDoom3All256.

== New Command Line Arguments ==

These are in-addition to those of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256].

=== unicodeMap <file> ===
Example:

-unicodeMap "./Test/cp1251.txt"

You can edit the unicodeMap file in advance, to specify which particular glyphs you want to generate by suppressing unwanted glyphs, either by:

* Deleting an unwanted line (or block of lines) entirely, or
* Prepending a "#" to comment-out the line.

Also, this file format allows the Unicode value (e.g., "0x1234") to be replaced by 6 space characters, when the ISO or Windows standard leaves that character undefined.

In all 3 of those cases, every suppressed character in the output DAT file will be represented by the glyph that the font uses for U+0000. A hollow box is common.

IMPORTANT: If you edit lines, the remaining active glyph lines MUST be in ascending order by the 2-hex-digit codepoint value that starts each line. Otherwise, results will go astray.

=== startFileNumber <n> ===
When a set of TGA/DDS files are generated for a particular font size, by default the first file's name contains _0_, which increments for additional files. You can optionally specify a different 1- or 2-digit start number, e.g., "-startFileNumber 7". Why? Because...

* the file(s) you are generating are supplemental to, not replacements for, existing TGA/DDS files; and
* in this run, you are generating just one of the 3 possible font sizes (assuming each size has a different count of existing TGA/DDS files).

When you generate a supplemental set, the new DAT file has no knowledge of what's in the original set and its DAT file. You will have to interleave-edit the old and new DAT files (e.g., with reFont's REF files) to create a single DAT file spanning old and new glyphs. There may be a redundant NULL glyph in your new TGA set; just ignore it.

=== awayFromEdge <n> ===

Allows specifying in positive integer pixels (e.g., "-awayFromEdge 2") a small extra boundary at the top and left edges of the overall bitmap. This is for fonts like Mason where extra space (typically 2 pixels) is needed around every character to create a "glow variant". Routine glyph layout provides usually enough space for this except at the top and (arguably) left edges. See also the "compact" parameter.

Note: The spacing value is relative to 256x256 bitmaps. If you specify "hirez", then for proportionality, your specified value is doubled internally when laying out the 512x512 bitmaps.

=== compact ===
If specified (i.e, "-compact"), packs the character glyphs more closely together. Particularly recommended for 48pt fonts; it will generate roughly half the files.

Whether "compact" is specified or not, packing is controlled by simply "padding" each glyph’s bounding box. Specifically, this doesn’t change the bounding box, but adds pixel "padding" to just the right and bottom of the bounding box, a simple though asymmetric process. One reason for padding was given ExportFontToDoom3 author Grant Davies in code comments:

"Because of the way Doom 3 Indexes the texture page (using floating point numbers), it is unable to reference exact pixels – there is error. How much error, I don’t know. For this reason, the rectangles needs to be padded out."

Geep suspects that such error with the TDM engine is not really a problem. Likely some error in the past was due to editing with Q3Font and its low floating-point precision. Nevertheless, some padding is good because:

* For the Mason font, 2 pixels around each glyph are needed for "glow" effects (either done as a separate smudge font for /english/ or as a bidirection offset effect for /russian/.)
* Keeping glyphs separated improves visualization of boundaries with datBounds, and makes editing tweaks easier.

The "compact" setting restores Grant Davies' first algorithm, which just pads the bounding box by 5 pixels to the right and 5 pixels below.

Without "compact", the default is Grant Davies' second algorithm found in ExportFontToDoom3 v1.02. This likewise first pads each bounding box by 5 pixels to the right and 5 pixels below. It then further pads to make both the width and height a factor of 2; this makes 48pt quite sparse. (It is possible this improved rendering performance in 2005; not important now. Also, in practice for major fonts, much of this "factor of 2" spacing was overridden by subsequent Font Patcher work.)

=== hirez or hires ===
''Added with v1.1, March 2026''

Instead of 256x256 bitmaps (and associated DAT), this exports double-sized 512x512 bitmaps with larger, thus potentially-crisper glyphs. (TDM has had a few such 512x512 bitmaps for redrawn fonts since 2014.) Specifically, it:
* outputs requested 512x512 TGAs and their DAT(s).
* internally, doubles the pointsize requested of the TTF, resulting in 2x character glyph sizes. Because both the container bitmap and each glyph is (nominally) doubled in size, the [0...1] s, s2, t, t2 values stored in the DAT would be very similar to those for a 256x256 bitmap.
* Other DAT layout metrics remain as if scaled to a 256x256 layout:
** imageHeight
** imageWidth
** skip
** top (with bottom ignored as usual)
** pitch

For example, if you request –hirez with a carleton font in just 24pt type, it will create 512x512 files with usual names like carleton_0_24.tga, etc., and fontimage_24.dat, with the console showing “Exporting carleton 24pt”.
But internally, 48pt characters are drawn on the bitmaps. The imageHeight and imageWidth metrics will be as if the requested 24pt size was generated, so in effect causing the game engine to scale down by a factor of 2 from the 48pt glyph.

''TIPS on Using a HiRez DAT file''

If subsequently using Refont to make a REF file from this DAT, add the “scaling_ok” option, to suppress otherwise voluminous console warnings about per-character scaling.

If you further plan to generate bounds visualizations with datBounds:
* For 512x512 bitmaps, you must generate from the REF file, not directly from DAT.
* Be sure to first edit the REF to add headers of the form:

# bitmap_<n>_size=512

, where <n> is 0 to 9, and refers to shaders present in the REF file with names like, e.g., carleton_3_48.tga; n would be 3 for this.

* datBounds also has a worthwhile “scaling_ok” option.
* Uncommonly, the raw_metrics option may be of interest.

=== bolding <n> ===
''Added with v1.1, March 2026''

Sometimes, a TTF font does not offer a “bold” variant, or, more generally, a font’s overall stroke thickness is not ideal. It is possible to alter character outlines, then render those as bitmap glyphs.
The result is usually better than post-bitmap thickening or thinning. The FreeType library offers an embolding function for outline alteration, used here.

The integer parameter <n> is in units of 1/64th pixel. A positive value adjusts the outline to embolden the character. Negative thins. The change affects both the overall height and width of the outline.
You may think of the left and bottom character borders as unchanged. The allowed range of <n> is from -128 (i.e., -2 pixels) to 256 (4 pixels). The -2 limit is arbitrary, but for sanity. The 4 limit is the maximum FreeType permits.

Caution: The adjustment algorithm moves the outline controls points, but doesn't change the number of such points;
this means that certain situations like acute angles or intersections are sometimes handled incorrectly.

== Changed Behavior for Font Title from ExportFontToDoom3All256 ==
In ExportFontToDoom3All256, if the font title was more that 20 characters long, it would truncate it to fit in the DAT file as part of the shader names (i.e., paths to TGA files). But this threshold was wrong. Now, truncation and a warning happens if the font title is more that 17 characters long (or 16 if generated TGAs include any with a 2-digit count instead of 1-digit). If truncation occurs, the user is asked to consider using or revising the -name argument.

== Downloads ==
Release v1.1 of 2025-03-03:
* [https://drive.google.com/file/d/1f3Jj53qtJGIp0_mz7Riing9Fi8ESFDr5/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_exe.zip] . Windows binary and required archived versions of FreeType and DevIL DLLs.
* [https://drive.google.com/file/d/1nutMBfcIWw63wNTUdnlnzP397tGVpnpd/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_source_project.zip] . The C++ project file with source code, including source & build project of archived library.

Release 1 of 2024-09-10:
* [https://drive.google.com/file/d/1MqoOfhc5-ovoxoHfRquYAcIEdHEOJAQV/view?usp=sharing ExportUnicodeFontToDoom3_release_1_exe.zip]
* [https://drive.google.com/file/d/1Frk_byfdtCcMqdr27ulw1XyuFj8vYp9x/view?usp=sharing ExportUnicodeFontToDoom3_release_1_source_project.zip]

== See Also ==
The Cyrillic coverage of Lora Regular TTF font, projected to used as Russian Mason supplement in TDM 2.14, may be viewed and font downloaded [https://www.fontsquirrel.com/fonts/lora?filter%5Bclassifications%5D%5B0%5D=serif&filter%5Blanguages%5D%5B0%5D=cyrillic#eula here].

I18N - Charset

2026-03-15T20:59:00Z

Geep: /* Notes */

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

This ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Table Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6.

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14. Similar Stone 48pt and Carleton 24pt improvements are planned for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

I18N - Charset

2026-03-15T20:58:07Z

Geep: Added note 2 about avoiding non-breaking space & soft hyphen

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

This ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [1]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [1]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]''' [2]
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]''' [2]
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

==== Notes ====

'''[1]''' As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Starting with TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

'''[2]''' Avoid using the non-breaking space (NBSP, 0xA0) and the soft hyphen (SHY, 0xAD) in your strings. The TDM engine has no code to respect these during word wrap. Font maintainers: probably map NBSP to the <space> glyph, SHY to undefined/hollow box or zero-sized box.

==== Corresponding Unicode ====

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6.

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14. Similar Stone 48pt and Carleton 24pt improvements are planned for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

ExportUnicodeFontToDoom3

2026-03-03T21:57:54Z

Geep: /* Downloads */ Add 1.1 links. Also fix 1.0 source project link

''By Geep, 2025''

== Introduction ==

In 2025, kalinovka in [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization Font localization] sought to extend TDM’s Mason 48pt font, used in the main menu, to include missing Cyrillic glyphs. This would allow this font to be used in an FM and still support a Russian translation.

This offshoot of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256] is a generalized response to that. The main idea to select an input TTF font that includes not just ASCII or ANSI, but offers additional Unicode characters, like Cyrillic. The program still limits output to a maximum of 256 characters, consistent with the DAT format.

To achieve this, it reads in an external human-readable "unicodeMap" file, in Unicode.org’s "Format A". This format provides a mapping from the traditional 8-bit encoding that TDM uses to the corresponding UCS (Unicode 16-bit) value. Unicode.org provides stock files for standard ISO and Windows 8-bit encodings. Of specific interest here is [https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT cp1251.txt for Cyrillic]. This requires just trivial editing for [https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset TDM-specific codepoints]. As discussed below, you can further edit a unicodeMap file in advance, if you want to generate just a subset of glyphs.

More broadly, this program supersedes ExportFontToDoom3 and ExportFontToDoom3All256.

== New Command Line Arguments ==

These are in-addition to those of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256].

=== unicodeMap <file> ===
Example:

-unicodeMap "./Test/cp1251.txt"

You can edit the unicodeMap file in advance, to specify which particular glyphs you want to generate by suppressing unwanted glyphs, either by:

* Deleting an unwanted line (or block of lines) entirely, or
* Prepending a "#" to comment-out the line.

Also, this file format allows the Unicode value (e.g., "0x1234") to be replaced by 6 space characters, when the ISO or Windows standard leaves that character undefined.

In all 3 of those cases, every suppressed character in the output DAT file will be represented by the glyph that the font uses for U+0000. A hollow box is common.

=== startFileNumber <n> ===
When a set of TGA/DDS files are generated for a particular font size, by default the first file's name contains _0_, which increments for additional files. You can optionally specify a different 1- or 2-digit start number, e.g., "-startFileNumber 7". Why? Because...

* the file(s) you are generating are supplemental to, not replacements for, existing TGA/DDS files; and
* in this run, you are generating just one of the 3 possible font sizes (assuming each size has a different count of existing TGA/DDS files).

When you generate a supplemental set, the new DAT file has no knowledge of what's in the original set and its DAT file. You will have to interleave-edit the old and new DAT files (e.g., with reFont's REF files) to create a single DAT file spanning old and new glyphs. There may be a redundant NULL glyph in your new TGA set; just ignore it.

=== awayFromEdge <n> ===

Allows specifying in positive integer pixels (e.g., "-awayFromEdge 2") a small extra boundary at the top and left edges of the overall bitmap. This is for fonts like Mason where extra space (typically 2 pixels) is needed around every character to create a "glow variant". Routine glyph layout provides usually enough space for this except at the top and (arguably) left edges. See also the "compact" parameter.

Note: The spacing value is relative to 256x256 bitmaps. If you specify "hirez", then for proportionality, your specified value is doubled internally when laying out the 512x512 bitmaps.

=== compact ===
If specified (i.e, "-compact"), packs the character glyphs more closely together. Particularly recommended for 48pt fonts; it will generate roughly half the files.

Whether "compact" is specified or not, packing is controlled by simply "padding" each glyph’s bounding box. Specifically, this doesn’t change the bounding box, but adds pixel "padding" to just the right and bottom of the bounding box, a simple though asymmetric process. One reason for padding was given ExportFontToDoom3 author Grant Davies in code comments:

"Because of the way Doom 3 Indexes the texture page (using floating point numbers), it is unable to reference exact pixels – there is error. How much error, I don’t know. For this reason, the rectangles needs to be padded out."

Geep suspects that such error with the TDM engine is not really a problem. Likely some error in the past was due to editing with Q3Font and its low floating-point precision. Nevertheless, some padding is good because:

* For the Mason font, 2 pixels around each glyph are needed for "glow" effects (either done as a separate smudge font for /english/ or as a bidirection offset effect for /russian/.)
* Keeping glyphs separated improves visualization of boundaries with datBounds, and makes editing tweaks easier.

The "compact" setting restores Grant Davies' first algorithm, which just pads the bounding box by 5 pixels to the right and 5 pixels below.

Without "compact", the default is Grant Davies' second algorithm found in ExportFontToDoom3 v1.02. This likewise first pads each bounding box by 5 pixels to the right and 5 pixels below. It then further pads to make both the width and height a factor of 2; this makes 48pt quite sparse. (It is possible this improved rendering performance in 2005; not important now. Also, in practice for major fonts, much of this "factor of 2" spacing was overridden by subsequent Font Patcher work.)

=== hirez or hires ===
''Added with v1.1, March 2026''

Instead of 256x256 bitmaps (and associated DAT), this exports double-sized 512x512 bitmaps with larger, thus potentially-crisper glyphs. (TDM has had a few such 512x512 bitmaps for redrawn fonts since 2014.) Specifically, it:
* outputs requested 512x512 TGAs and their DAT(s).
* internally, doubles the pointsize requested of the TTF, resulting in 2x character glyph sizes. Because both the container bitmap and each glyph is (nominally) doubled in size, the [0...1] s, s2, t, t2 values stored in the DAT would be very similar to those for a 256x256 bitmap.
* Other DAT layout metrics remain as if scaled to a 256x256 layout:
** imageHeight
** imageWidth
** skip
** top (with bottom ignored as usual)
** pitch

For example, if you request –hirez with a carleton font in just 24pt type, it will create 512x512 files with usual names like carleton_0_24.tga, etc., and fontimage_24.dat, with the console showing “Exporting carleton 24pt”.
But internally, 48pt characters are drawn on the bitmaps. The imageHeight and imageWidth metrics will be as if the requested 24pt size was generated, so in effect causing the game engine to scale down by a factor of 2 from the 48pt glyph.

''TIPS on Using a HiRez DAT file''

If subsequently using Refont to make a REF file from this DAT, add the “scaling_ok” option, to suppress otherwise voluminous console warnings about per-character scaling.

If you further plan to generate bounds visualizations with datBounds:
* For 512x512 bitmaps, you must generate from the REF file, not directly from DAT.
* Be sure to first edit the REF to add headers of the form:

# bitmap_<n>_size=512

, where <n> is 0 to 9, and refers to shaders present in the REF file with names like, e.g., carleton_3_48.tga; n would be 3 for this.

* datBounds also has a worthwhile “scaling_ok” option.
* Uncommonly, the raw_metrics option may be of interest.

=== bolding <n> ===
''Added with v1.1, March 2026''

Sometimes, a TTF font does not offer a “bold” variant, or, more generally, a font’s overall stroke thickness is not ideal. It is possible to alter character outlines, then render those as bitmap glyphs.
The result is usually better than post-bitmap thickening or thinning. The FreeType library offers an embolding function for outline alteration, used here.

The integer parameter <n> is in units of 1/64th pixel. A positive value adjusts the outline to embolden the character. Negative thins. The change affects both the overall height and width of the outline.
You may think of the left and bottom character borders as unchanged. The allowed range of <n> is from -128 (i.e., -2 pixels) to 256 (4 pixels). The -2 limit is arbitrary, but for sanity. The 4 limit is the maximum FreeType permits.

Caution: The adjustment algorithm moves the outline controls points, but doesn't change the number of such points;
this means that certain situations like acute angles or intersections are sometimes handled incorrectly.

== Changed Behavior for Font Title from ExportFontToDoom3All256 ==
In ExportFontToDoom3All256, if the font title was more that 20 characters long, it would truncate it to fit in the DAT file as part of the shader names (i.e., paths to TGA files). But this threshold was wrong. Now, truncation and a warning happens if the font title is more that 17 characters long (or 16 if generated TGAs include any with a 2-digit count instead of 1-digit). If truncation occurs, the user is asked to consider using or revising the -name argument.

== Downloads ==
Release v1.1 of 2025-03-03:
* [https://drive.google.com/file/d/1f3Jj53qtJGIp0_mz7Riing9Fi8ESFDr5/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_exe.zip] . Windows binary and required archived versions of FreeType and DevIL DLLs.
* [https://drive.google.com/file/d/1nutMBfcIWw63wNTUdnlnzP397tGVpnpd/view?usp=sharing ExportUnicodeFontToDoom3_release_1_1_source_project.zip] . The C++ project file with source code, including source & build project of archived library.

Release 1 of 2024-09-10:
* [https://drive.google.com/file/d/1MqoOfhc5-ovoxoHfRquYAcIEdHEOJAQV/view?usp=sharing ExportUnicodeFontToDoom3_release_1_exe.zip]
* [https://drive.google.com/file/d/1Frk_byfdtCcMqdr27ulw1XyuFj8vYp9x/view?usp=sharing ExportUnicodeFontToDoom3_release_1_source_project.zip]

== See Also ==
The Cyrillic coverage of Lora Regular TTF font, projected to used as Russian Mason supplement in TDM 2.14, may be viewed and font downloaded [https://www.fontsquirrel.com/fonts/lora?filter%5Bclassifications%5D%5B0%5D=serif&filter%5Blanguages%5D%5B0%5D=cyrillic#eula here].

ExportUnicodeFontToDoom3

2026-03-02T21:01:07Z

Geep: Added 512x512 for awayFromEdge, hirez, bolding

''By Geep, 2025''

== Introduction ==

In 2025, kalinovka in [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization Font localization] sought to extend TDM’s Mason 48pt font, used in the main menu, to include missing Cyrillic glyphs. This would allow this font to be used in an FM and still support a Russian translation.

This offshoot of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256] is a generalized response to that. The main idea to select an input TTF font that includes not just ASCII or ANSI, but offers additional Unicode characters, like Cyrillic. The program still limits output to a maximum of 256 characters, consistent with the DAT format.

To achieve this, it reads in an external human-readable "unicodeMap" file, in Unicode.org’s "Format A". This format provides a mapping from the traditional 8-bit encoding that TDM uses to the corresponding UCS (Unicode 16-bit) value. Unicode.org provides stock files for standard ISO and Windows 8-bit encodings. Of specific interest here is [https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT cp1251.txt for Cyrillic]. This requires just trivial editing for [https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset TDM-specific codepoints]. As discussed below, you can further edit a unicodeMap file in advance, if you want to generate just a subset of glyphs.

More broadly, this program supersedes ExportFontToDoom3 and ExportFontToDoom3All256.

== New Command Line Arguments ==

These are in-addition to those of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256].

=== unicodeMap <file> ===
Example:

-unicodeMap "./Test/cp1251.txt"

You can edit the unicodeMap file in advance, to specify which particular glyphs you want to generate by suppressing unwanted glyphs, either by:

* Deleting an unwanted line (or block of lines) entirely, or
* Prepending a "#" to comment-out the line.

Also, this file format allows the Unicode value (e.g., "0x1234") to be replaced by 6 space characters, when the ISO or Windows standard leaves that character undefined.

In all 3 of those cases, every suppressed character in the output DAT file will be represented by the glyph that the font uses for U+0000. A hollow box is common.

=== startFileNumber <n> ===
When a set of TGA/DDS files are generated for a particular font size, by default the first file's name contains _0_, which increments for additional files. You can optionally specify a different 1- or 2-digit start number, e.g., "-startFileNumber 7". Why? Because...

* the file(s) you are generating are supplemental to, not replacements for, existing TGA/DDS files; and
* in this run, you are generating just one of the 3 possible font sizes (assuming each size has a different count of existing TGA/DDS files).

When you generate a supplemental set, the new DAT file has no knowledge of what's in the original set and its DAT file. You will have to interleave-edit the old and new DAT files (e.g., with reFont's REF files) to create a single DAT file spanning old and new glyphs. There may be a redundant NULL glyph in your new TGA set; just ignore it.

=== awayFromEdge <n> ===

Allows specifying in positive integer pixels (e.g., "-awayFromEdge 2") a small extra boundary at the top and left edges of the overall bitmap. This is for fonts like Mason where extra space (typically 2 pixels) is needed around every character to create a "glow variant". Routine glyph layout provides usually enough space for this except at the top and (arguably) left edges. See also the "compact" parameter.

Note: The spacing value is relative to 256x256 bitmaps. If you specify "hirez", then for proportionality, your specified value is doubled internally when laying out the 512x512 bitmaps.

=== compact ===
If specified (i.e, "-compact"), packs the character glyphs more closely together. Particularly recommended for 48pt fonts; it will generate roughly half the files.

Whether "compact" is specified or not, packing is controlled by simply "padding" each glyph’s bounding box. Specifically, this doesn’t change the bounding box, but adds pixel "padding" to just the right and bottom of the bounding box, a simple though asymmetric process. One reason for padding was given ExportFontToDoom3 author Grant Davies in code comments:

"Because of the way Doom 3 Indexes the texture page (using floating point numbers), it is unable to reference exact pixels – there is error. How much error, I don’t know. For this reason, the rectangles needs to be padded out."

Geep suspects that such error with the TDM engine is not really a problem. Likely some error in the past was due to editing with Q3Font and its low floating-point precision. Nevertheless, some padding is good because:

* For the Mason font, 2 pixels around each glyph are needed for "glow" effects (either done as a separate smudge font for /english/ or as a bidirection offset effect for /russian/.)
* Keeping glyphs separated improves visualization of boundaries with datBounds, and makes editing tweaks easier.

The "compact" setting restores Grant Davies' first algorithm, which just pads the bounding box by 5 pixels to the right and 5 pixels below.

Without "compact", the default is Grant Davies' second algorithm found in ExportFontToDoom3 v1.02. This likewise first pads each bounding box by 5 pixels to the right and 5 pixels below. It then further pads to make both the width and height a factor of 2; this makes 48pt quite sparse. (It is possible this improved rendering performance in 2005; not important now. Also, in practice for major fonts, much of this "factor of 2" spacing was overridden by subsequent Font Patcher work.)

=== hirez or hires ===
''Added with v1.1, March 2026''

Instead of 256x256 bitmaps (and associated DAT), this exports double-sized 512x512 bitmaps with larger, thus potentially-crisper glyphs. (TDM has had a few such 512x512 bitmaps for redrawn fonts since 2014.) Specifically, it:
* outputs requested 512x512 TGAs and their DAT(s).
* internally, doubles the pointsize requested of the TTF, resulting in 2x character glyph sizes. Because both the container bitmap and each glyph is (nominally) doubled in size, the [0...1] s, s2, t, t2 values stored in the DAT would be very similar to those for a 256x256 bitmap.
* Other DAT layout metrics remain as if scaled to a 256x256 layout:
** imageHeight
** imageWidth
** skip
** top (with bottom ignored as usual)
** pitch

For example, if you request –hirez with a carleton font in just 24pt type, it will create 512x512 files with usual names like carleton_0_24.tga, etc., and fontimage_24.dat, with the console showing “Exporting carleton 24pt”.
But internally, 48pt characters are drawn on the bitmaps. The imageHeight and imageWidth metrics will be as if the requested 24pt size was generated, so in effect causing the game engine to scale down by a factor of 2 from the 48pt glyph.

''TIPS on Using a HiRez DAT file''

If subsequently using Refont to make a REF file from this DAT, add the “scaling_ok” option, to suppress otherwise voluminous console warnings about per-character scaling.

If you further plan to generate bounds visualizations with datBounds:
* For 512x512 bitmaps, you must generate from the REF file, not directly from DAT.
* Be sure to first edit the REF to add headers of the form:

# bitmap_<n>_size=512

, where <n> is 0 to 9, and refers to shaders present in the REF file with names like, e.g., carleton_3_48.tga; n would be 3 for this.

* datBounds also has a worthwhile “scaling_ok” option.
* Uncommonly, the raw_metrics option may be of interest.

=== bolding <n> ===
''Added with v1.1, March 2026''

Sometimes, a TTF font does not offer a “bold” variant, or, more generally, a font’s overall stroke thickness is not ideal. It is possible to alter character outlines, then render those as bitmap glyphs.
The result is usually better than post-bitmap thickening or thinning. The FreeType library offers an embolding function for outline alteration, used here.

The integer parameter <n> is in units of 1/64th pixel. A positive value adjusts the outline to embolden the character. Negative thins. The change affects both the overall height and width of the outline.
You may think of the left and bottom character borders as unchanged. The allowed range of <n> is from -128 (i.e., -2 pixels) to 256 (4 pixels). The -2 limit is arbitrary, but for sanity. The 4 limit is the maximum FreeType permits.

Caution: The adjustment algorithm moves the outline controls points, but doesn't change the number of such points;
this means that certain situations like acute angles or intersections are sometimes handled incorrectly.

== Changed Behavior for Font Title from ExportFontToDoom3All256 ==
In ExportFontToDoom3All256, if the font title was more that 20 characters long, it would truncate it to fit in the DAT file as part of the shader names (i.e., paths to TGA files). But this threshold was wrong. Now, truncation and a warning happens if the font title is more that 17 characters long (or 16 if generated TGAs include any with a 2-digit count instead of 1-digit). If truncation occurs, the user is asked to consider using or revising the -name argument.

== Downloads ==
[COMING SOON - v1.1]

Release 1 of 2024-09-10:
* [https://drive.google.com/file/d/1MqoOfhc5-ovoxoHfRquYAcIEdHEOJAQV/view?usp=sharing ExportUnicodeFontToDoom3_release_1_exe.zip] . Windows binary and required archived versions of FreeType and DevIL DLLs.
* [https://drive.google.com/file/d/1Frk_byfdtCcMqdr27ulw1XyuFj8vYp9x/view?usp=sharing ExportUnicodeFontToDoom3_release_1_source_project.zip] . The C++ project file with source code, including source & build project of archived library.

The Cyrillic coverage of Lora Regular TTF font, projected to used as Russian Mason supplement in TDM 2.14, may be viewed and font downloaded [https://www.fontsquirrel.com/fonts/lora?filter%5Bclassifications%5D%5B0%5D=serif&filter%5Blanguages%5D%5B0%5D=cyrillic#eula here].

Rebuild all lang Program

2026-02-14T16:15:29Z

Geep: /* Downloads */ Update contents of rebuilt_all_lang.zip to include LICENSE.txt

''by Geep, 2026''

==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of most helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use '''rebuild_all_lang'''. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
* deciding in advance which *.lang files are the current directory
* if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As examples, the program distribution includes 2 typical stock preambles.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are ''always'' processed in the order shown. If a particular *.lang is missing, that is merely mentioned to the console, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

Within each of the source *.lang files, comments take only two forms:
* as a preamble; as discussed above, the first line is harvested, the rest ignored.
* as trailing "// ..." at the ends of lines. These will be propagated to the corresponding lines of the rebuilt all.lang. (These will be treated as in the same 8-bit language encoding as the rest of the text in the block. Because all supported encodings include ASCII, English comments will be preserved.)

==== Downloads ====
v 1.1 [Recommended]. This upgrades to a non-deprecated interface to Windows 10/11's built-in encoding support, and adds custom code to fix 1.0's problem with [Romanian]. It was roundtrip tested against AirPocket's new all.lang. See the release notes in the .cpp file for details.
* [https://drive.google.com/file/d/1j7941Sjy969XZvKEkHuHxs2Ikz5DVp46/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/178UsLBFpPPce6N-LPwSrG84VRGeLO35i/view?usp=sharing rebuilt_all_lang_1_1.zip - source code: a .cpp and .sln file]

v 1.0 Source Code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code], consisting of a .cpp, .sln, and open-source license file.

Example preamble files (rename to preamble_utf8.txt to use):
* [https://drive.google.com/file/d/1bOWXv8Ju1DktaNYe2M8Bo-V7zAg2bNJ9/view?usp=sharing preamble_utf8[traditional<nowiki>]</nowiki>.txt]
* [https://drive.google.com/file/d/1QKJvG6FoAzuI7njO5fnOQCgwbXQdWqQe/view?usp=sharing preamble_utf8[modern for FM<nowiki>]</nowiki>.txt]

==== See Also ====
* [[Gen_Lang_Programs]]

{{i18n}} {{editing}}

Rebuild all lang Program

2026-02-01T20:42:37Z

Geep: /* Downloads */ links to 1.1 distribution

''by Geep, 2026''

==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of most helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use '''rebuild_all_lang'''. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
* deciding in advance which *.lang files are the current directory
* if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As examples, the program distribution includes 2 typical stock preambles.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are ''always'' processed in the order shown. If a particular *.lang is missing, that is merely mentioned to the console, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

Within each of the source *.lang files, comments take only two forms:
* as a preamble; as discussed above, the first line is harvested, the rest ignored.
* as trailing "// ..." at the ends of lines. These will be propagated to the corresponding lines of the rebuilt all.lang. (These will be treated as in the same 8-bit language encoding as the rest of the text in the block. Because all supported encodings include ASCII, English comments will be preserved.)

==== Downloads ====
v 1.1 [Recommended]. This upgrades to a non-deprecated interface to Windows 10/11's built-in encoding support, and adds custom code to fix 1.0's problem with [Romanian]. It was roundtrip tested against AirPocket's new all.lang. See the release notes in the .cpp file for details.
* [https://drive.google.com/file/d/1j7941Sjy969XZvKEkHuHxs2Ikz5DVp46/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/178UsLBFpPPce6N-LPwSrG84VRGeLO35i/view?usp=sharing rebuilt_all_lang_1_1.zip - source code: a .cpp and .sln file]

v 1.0 Source Code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code: a .cpp and .sln file]

Example preamble files (rename to preamble_utf8.txt to use):
* [https://drive.google.com/file/d/1bOWXv8Ju1DktaNYe2M8Bo-V7zAg2bNJ9/view?usp=sharing preamble_utf8[traditional<nowiki>]</nowiki>.txt]
* [https://drive.google.com/file/d/1QKJvG6FoAzuI7njO5fnOQCgwbXQdWqQe/view?usp=sharing preamble_utf8[modern for FM<nowiki>]</nowiki>.txt]

==== See Also ====
* [[Gen_Lang_Programs]]

{{i18n}} {{editing}}

Rebuild all lang Program

2026-02-01T20:38:54Z

Geep: Update for v 1.1

''by Geep, 2026''

==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of most helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use '''rebuild_all_lang'''. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
* deciding in advance which *.lang files are the current directory
* if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As examples, the program distribution includes 2 typical stock preambles.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are ''always'' processed in the order shown. If a particular *.lang is missing, that is merely mentioned to the console, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

Within each of the source *.lang files, comments take only two forms:
* as a preamble; as discussed above, the first line is harvested, the rest ignored.
* as trailing "// ..." at the ends of lines. These will be propagated to the corresponding lines of the rebuilt all.lang. (These will be treated as in the same 8-bit language encoding as the rest of the text in the block. Because all supported encodings include ASCII, English comments will be preserved.)

==== Downloads ====
v 1.1 [Recommended]. This upgrades to a non-deprecated interface to Windows 10/11's built-in encoding support, and adds custom code to fix 1.0's problem with [Romanian]. It was roundtrip tested against AirPocket's new all.lang. See the release notes in the .cpp file for details.
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code: a .cpp and .sln file]

v 1.0 Source Code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code: a .cpp and .sln file]

Example preamble files (rename to preamble_utf8.txt to use):
* [https://drive.google.com/file/d/1bOWXv8Ju1DktaNYe2M8Bo-V7zAg2bNJ9/view?usp=sharing preamble_utf8[traditional<nowiki>]</nowiki>.txt]
* [https://drive.google.com/file/d/1QKJvG6FoAzuI7njO5fnOQCgwbXQdWqQe/view?usp=sharing preamble_utf8[modern for FM<nowiki>]</nowiki>.txt]
==== See Also ====
* [[Gen_Lang_Programs]]

{{i18n}} {{editing}}

CBinaryFrobMover

2026-01-27T16:08:20Z

Geep: /* Spawnargs */ lock_picktype can't use *

== CBinaryFrobMover ==
The corresponding entityDef is '''atdm:mover_binarymover_base'''

This is the base class for all kind of TDM movers like doors, levers and buttons. The class is designed for movers with two final states, namely open and closed. "Open" and "closed" are abstract definitions and just refer to the "one" and the "other" state of the mover. All movers are considered to spawn "closed", until specifically specified otherwise.

The class provides a set of virtual C++ methods which can be specialised by their subclasses to implement the correct behaviour. It also supports a number if spawnargs which allow for easy customisation right in the editor.

=== Spawnargs ===
* '''rotate''': (angles) Describes the angles (pitch, yaw, roll) the mover will rotate from its closed to its open position (default is: "90 0 0").
* '''translate''': (vector) Describes the relative movement of the origin from the closed position to the open position (default is "0 0 0" = no movement).
* '''translate_speed''': (float) Is the linear velocity in units per second (defaults to "0", which means that the idMover's "move_time" value is in effect).

* '''open''': (1/0) Specifies whether this frobmover spawns at the open position. Can be used to let doors be open right at map start (default is "0").
* '''locked''': (1/0) Specifies whether this frobmover is locked (default is "0").

* '''pickable''' (1/0) If set to 1, is pickable by the player's lockpicks.
* '''lock_picktype''' (string) This is a sequence of characters defining the lockpick types which need to be used on this door. For instance, 'ts' means that the player must use the "triangle" lockpick ('t') and the "snake" lockpick ('s') - in this order - to pick this lock. [At one time, it was said that it's also possible to define a star "*", which matches all lockpick types. Doesn't work now.]
* '''lock_pins''' (string) Defines the number of samples per pin to be created for this lock, example: "56" will create two patterns, one with 5 samples, the other with 6 samples. The minimum is 5.

* '''open_on_unlock''': (1/0) When set to 1, the mover will automatically open when unlocked.
* '''interruptable''': (1/0) When set to 1, the mover can be stopped by frobbing it while moving. Doors are interruptable by default, whereas levers are not.
* '''stop_when_blocked''': (1/0) Set stop_when_blocked to 0 to let this entity keep moving after the blocking entity is out of the way. Default is "1".
* '''push_player''': (1/0) Set this to 1 to let this entity push the player (default is 0). Note: belongs to idMover class.

* '''start_rotate''': (Angles) Defines the angles (pitch, yaw, roll) the mover should have at spawn time (to let the mover start out half-open, for instance). Defaults to "0 0 0".
* "start_position": (Vector) Defines the position the mover should have at spawn time (to let the mover start out open, for instance). Defaults to "0 0 0".
* '''first_frob_open''': (1/0) This helps to disambiguate the behaviour when a mover starts at a half-open position. When this is set to "1" the first frob will make the mover open. Defaults to "0", which means that half-open doors will close on first frob by default.

* '''snd_open''' (Soundshader) The sound to be played when the door starts to open after being fully closed.
* '''snd_close''' (Soundshader) The sound to be played when the door reaches its fully closed position.
* '''snd_locked''' (Soundshader) The sound to be played when the mover becomes locked.
* '''snd_unlock''' (Soundshader) The sound to be played when the mover unlocks.

* '''snd_lockpick_pin_NN''' (soundshader) Defines the sample sound for the pin with NN being in the range 00..14. The number must have a leading zero in it (e.g. '02').
* '''snd_lockpick_pin_sweetspot''' (soundshader) Defines the sweet spot sound to be inserted into a pattern.
* '''snd_lockpick_lock_picked''' (soundshader) Is played when the entire lock is successfully picked.
* '''snd_lockpick_pin_success''' (soundshader) Is played when a single pin is successfully picked.
* '''snd_lockpick_pin_fail''' (soundshader) Is played when the player fails to pick a pin.
* '''snd_lockpick_pick_wrong''' (soundshader) Is played when the user either attempts to use the wrong lockpick type or the door is not locked or already picked.

* '''trigger_on_open''': (1/0) If set to "1", this binary mover will trigger its targets when it starts out completely closed and is opened. Default is "0".
* '''trigger_on_close''': (1/0) If set to 1, this binary mover will trigger its targets when it completely closes after being open. Default is "0".
* '''trigger_when_opened''': (1/0) If set to 1, this binary mover will trigger its targets when it is completely opened. Default is "0".

* '''auto_close_time''': (float) Set this to something >= 0 to let the mover automatically close (again) after this time when being fully opened (measured in seconds). Defaults to -1, which means 'do not autoclose'. The event is also activated when the mover starts at the open position at map start.
* '''auto_open_time''': (float) Set this to something >= 0 to let the mover automatically open (again) after this time when being fully closed (measured in seconds). Defaults to -1, which means 'do not autoopen'. The event is also activated when the mover starts at the closed position at map start.

* '''impulse_thresh_open''': (float) Defines the minimum impulse which needs to be applied to this door before it starts to open. If 0, no open impulse is defined. Default is "0".
* '''impulse_thresh_close''': (float) Defines the minimum impulse which needs to be applied to this door before it starts to close. If 0, no close impulse is defined. Default is "0".
* '''impulse_dir_open''': (vector) Defines the direction the open impulse needs to be applied in. Default is '0 0 0'.
* '''impulse_dir_close''': (vector) Defines the direction the close impulse needs to be applied in. Default is '0 0 0'.

* '''state_change_callback''': (script function) Defines the (global) script function which gets called when the mover changes its state. Function signature is: '''void statChangeCallback(entity self, bool open, bool locked, bool interrupted);'''

=== Script Events ===

;scriptEvent void Open();
: Opens the frobmover, regardless of its previous state. The mover will not move when it's locked.

;scriptEvent void Close();
: Closes the frobmover, regardless of its previous state.

;scriptEvent void ToggleOpen();
: Toggles the mover state. Closes when fully open, opens when fully closed. If the mover is "interrupted" (e.g. when the player frobbed the mover in between), the move direction depends on the state of the internal "intent_open" flag.

; scriptEvent float IsOpen();
: Returns true (nonzero) if the mover is open, which is basically the same as "not closed". A mover is considered closed when it is at its close position.

;scriptEvent void Lock();
: Locks the mover. Calls to Open() will not succeed after this call.
;scriptEvent void Unlock();
: Unlocks the mover. Calls to Open() will succeed after this call. Depending on the value of the spawnarg "open_on_unlock" the mover might automatically open after this call.
; scriptEvent void ToggleLock();
: Toggles the lock state. Unlocked movers will be locked and vice versa. The notes above concerning Unlock() still apply if this call unlocks the mover.
; scriptEvent float IsLocked();
: Returns true (nonzero) if the mover is currently locked.
; scriptEvent float IsPickable();
: Returns true (nonzero) if this mover is pickable.

=== C++ Methods and Events ===
The class declaration can be found in ''DarkMod/BinaryFrobMover.h''. Apart from the mandatory Spawn/Save/Restore triple, a set of virtual functions are defined, which can be overridden by the subclasses to specialise the mover.

Note: This is just an abstract. A detailed description of these events can be found in the BinaryFrobMover.h header itself.

As many spawnargs refer to other entities, most of the setup work can be performed after all entities have been spawned. This is why the FrobMover base class provides a virtual PostSpawn() method which can be overridden by the subclasses to do work after all map entities have been spawned. Note: don't forget to call the base class!
// Gets called 16 ms after all entities have been spawned
virtual void PostSpawn();

The class provides a few virtual "interceptor" methods, which can be used to prevent the mover from changing its state. These are:
virtual bool PreOpen();
virtual bool PreClose();
virtual bool PreInterrupt();
virtual bool PreLock(bool bMaster);
virtual bool PreUnlock(bool bMaster);
These functions are called when the mover is about to perform the respective action. If these are returning TRUE, the mover has green light and it will start to open/close/lock/unlock/get interrupted. Returning FALSE will prevent the calling method from continuing. An example of such a use case is the CBinaryFrobMover::PreOpen() routine, which returns FALSE when the mover is locked. It also playes the "I'm locked" sound before returning.

There are a couple of "state change events", which get invoked when the mover has reached a certain state:
// Gets called when the mover actually starts to move, regardless what the state was beforehand.
// The boolean tells which state the mover is heading towards.
virtual void OnMoveStart(bool open);

// Gets called when the mover is about to move towards its "open" and "closed" position, resp..
virtual void OnStartOpen(bool wasClosed, bool bMaster);
virtual void OnStartClose(bool wasOpen, bool bMaster);

// Gets called when the mover has just reached its fully open/closed position. Does not get called when the mover didn't move.
virtual void OnOpenPositionReached();
virtual void OnClosedPositionReached();

// Gets called when the mover has just been interrupted.
virtual void OnInterrupt();

// Is called when the mover has just been locked/unlocked.
virtual void OnLock(bool bMaster);
virtual void OnUnlock(bool bMaster);

General note on overriding these events: Althought most default implementations are empty, it's still advisable to call the base class from the overriding function. Default behaviour might be changed in the future, so always call the base class, unless you really need to prevent the default action from being executed.

{{coding}} {{editing}}

Rebuild all lang Program

2026-01-23T18:15:07Z

Geep: /* Usage and Example */

''by Geep, 2026''

'''HOLD OFF ON USING THIS! Further round-trip testing indicates a problem needing more work.'''

==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use '''rebuild_all_lang'''. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
* deciding in advance which *.lang files are the current directory
* if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As an example, the program distribution includes a typical stock preamble.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are always processed in the order shown. If a particular *.lang is missing, that is handled quietly, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

==== Downloads ====
v 1.0 Source Code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code: a .cpp and .sln file]

Example preamble files (rename to preamble_utf8.txt to use):
* [https://drive.google.com/file/d/1bOWXv8Ju1DktaNYe2M8Bo-V7zAg2bNJ9/view?usp=sharing preamble_utf8[traditional<nowiki>]</nowiki>.txt]
* [https://drive.google.com/file/d/1QKJvG6FoAzuI7njO5fnOQCgwbXQdWqQe/view?usp=sharing preamble_utf8[modern for FM<nowiki>]</nowiki>.txt]
==== See Also ====
* [[Gen_Lang_Programs]]

{{i18n}} {{editing}}

Rebuild all lang Program

2026-01-23T18:07:16Z

Geep: HOLD OFF ON USING THIS warning added

''by Geep, 2026''

'''HOLD OFF ON USING THIS! Further round-trip testing indicates a problem needing more work.'''

==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use '''rebuild_all_lang'''. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
- deciding in advance which *.lang files are the current directory
- if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As an example, the program distribution includes a typical stock preamble.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are always processed in the order shown. If a particular *.lang is missing, that is handled quietly, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

==== Downloads ====
v 1.0 Source Code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code: a .cpp and .sln file]

Example preamble files (rename to preamble_utf8.txt to use):
* [https://drive.google.com/file/d/1bOWXv8Ju1DktaNYe2M8Bo-V7zAg2bNJ9/view?usp=sharing preamble_utf8[traditional<nowiki>]</nowiki>.txt]
* [https://drive.google.com/file/d/1QKJvG6FoAzuI7njO5fnOQCgwbXQdWqQe/view?usp=sharing preamble_utf8[modern for FM<nowiki>]</nowiki>.txt]
==== See Also ====
* [[Gen_Lang_Programs]]

{{i18n}} {{editing}}

I18N - Charset

2026-01-21T20:26:23Z

Geep: /* Russian */

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

This ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [note]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [note]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]'''
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]'''
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

[note] As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Planned for TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6.

Within any given font, character overage may be incomplete. A 2025 effort extended the Mason 48pt font to all 256 codepoints.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14. Similar Stone 48pt and Carleton 24pt improvements are planned for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

I18N - Charset

2026-01-21T20:09:12Z

Geep: /* European Character Implementation */ subsection headers, minor updates

== Introduction ==

The D3 code that handles the GUI bitmap font can only load a specific range of bytes as characters. To get the most out of the available entries, special charsets are used. The fonts (Carleton for the menu f.i.) are build/patched so that the right characters appear in the right place.

== Encodings ==

=== all.lang ===

This file is in '''UTF-8''', and converted with the help of the script '''devel/gen_lang.pl''':

perl devel/gen_lang.pl

This ensures that the generated language files are in their proper encodings (see below).

=== All other language files ===

Note that the language files (f.i. '''strings/german.lang''') as well as the readables and the FM dictionariaries are expected to be in the following encodings:

* '''Czech''', '''Hungarian''', '''Slovak''', '''Polish:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-2 ISO-8859-2] ('''not WIN-1250!)
* '''Russian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/Win-1251 WIN-1251]
* '''French:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-15 ISO-8859-15]
* '''Romanian:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-16 ISO-8859-16]
* '''All other languages:''' [https://secure.wikimedia.org/wikipedia/en/wiki/ISO/IEC_8859-1 ISO-8859-1] (German, Dutch, Danish, Swedish, Portuguese, etc.)

{{infobox|The core dictionaries are automatically generated in the right encoding, but make sure that you use the right encoding for the FM dictionary, too!}}

== Character remapping ==

The characters are remapped upon loading the dictionary/readable, from their native encoding to the special one that TDM uses and that is described here. Responsible for the remapping are [[I18N - Character mapping|mapping files]], f.i. "strings/czech.map". If a map file for a specific language is not found, "strings/default.map" is used instead, if this is not found, no remapping takes place.

See '''[[I18N - Character mapping|Character mapping]]''' for more information.

=== European Languages ===

This mapping is used for European languages, f.i. '''Czech''', '''French''', '''German''', '''Spanish''', '''Portuguese''', '''Polish'''. Note that the double accented characters in Hungarian '''Ő, ő, Ű and ű''' look a bit different from '''Ö, ö, Ü and ü'''!

In the table below, the original ISO 8859-1 characters are given in ''()'' below the TDM character.

'''Color code:'''

{{box|#f0d0d0|Character not usable by TDM|Unusable}}{{box|#d0e0d0|Character not yet used in TDM|Unused}}{{box|#c0ffc0|Character displayed in v1.08 or newer|Usable in v1.08}}{{box|#80f080|Character displayed in v2.03 or newer|Usable in v2.03}}{{box|#d0d0f0|Changed from the ISO-8859-1 default, usable by TDM 1.0 or newer|Changed from ISO 8859-1}}

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 95%" cellspacing=0 cellpadding=2 width=100%

|-
!
!…0
!…1
!…2
!…3
!…4
!…5
!…6
!…7
!…8
!…9
!…A
!…B
!…C
!…D
!…E
!…F

|-
!0…
|align='center' style='background: #f0d0d0'|00 '''–'''
|align='center' style='background: #f0d0d0'|01 '''–'''
|align='center' style='background: #f0d0d0'|02 '''–'''
|align='center' style='background: #f0d0d0'|03 '''–'''
|align='center' style='background: #f0d0d0'|04 '''–'''
|align='center' style='background: #f0d0d0'|05 '''–'''
|align='center' style='background: #f0d0d0'|06 '''–'''
|align='center' style='background: #f0d0d0'|07 '''–'''
|align='center' style='background: #f0d0d0'|08 '''–'''
|align='center' style='background: #f0d0d0'|09 '''–'''
|align='center' style='background: #f0d0d0'|0A '''–'''
|align='center' style='background: #f0d0d0'|0B '''–'''
|align='center' style='background: #f0d0d0'|0C '''–'''
|align='center' style='background: #f0d0d0'|0D '''–'''
|align='center' style='background: #f0d0d0'|0E '''–'''
|align='center' style='background: #f0d0d0'|0F '''–'''

|-
!1…
|align='center' style='background: #f0d0d0'|10 '''–'''
|align='center' style='background: #f0d0d0'|11 '''–'''
|align='center' style='background: #f0d0d0'|12 '''–'''
|align='center' style='background: #f0d0d0'|13 '''–'''
|align='center' style='background: #f0d0d0'|14 '''–'''
|align='center' style='background: #f0d0d0'|15 '''–'''
|align='center' style='background: #f0d0d0'|16 '''–'''
|align='center' style='background: #f0d0d0'|17 '''–'''
|align='center' style='background: #f0d0d0'|18 '''–'''
|align='center' style='background: #f0d0d0'|19 '''–'''
|align='center' style='background: #f0d0d0'|1A '''–'''
|align='center' style='background: #f0d0d0'|1B '''–'''
|align='center' style='background: #f0d0d0'|1C '''–'''
|align='center' style='background: #f0d0d0'|1D '''–'''
|align='center' style='background: #f0d0d0'|1E '''–'''
|align='center' style='background: #f0d0d0'|1F '''–'''

|-
!2…
|align='center'|20 ''' '''
|align='center'|21 '''!'''
|align='center'|22 '''"'''
|align='center'|23 '''#'''
|align='center'|24 '''$'''
|align='center'|25 '''%'''
|align='center'|26 '''&'''
|align='center'|27 '''''''
|align='center'|28 '''('''
|align='center'|29 ''')'''
|align='center'|2A '''*'''
|align='center'|2B '''+'''
|align='center'|2C ''','''
|align='center'|2D '''-'''
|align='center'|2E '''.'''
|align='center'|2F '''/'''

|-
!3…
|align='center'|30 '''0'''
|align='center'|31 '''1'''
|align='center'|32 '''2'''
|align='center'|33 '''3'''
|align='center'|34 '''4'''
|align='center'|35 '''5'''
|align='center'|36 '''6'''
|align='center'|37 '''7'''
|align='center'|38 '''8'''
|align='center'|39 '''9'''
|align='center'|3A ''':'''
|align='center'|3B ''';'''
|align='center'|3C '''<'''
|align='center'|3D '''='''
|align='center'|3E '''>'''
|align='center'|3F '''?'''

|-
!4…
|align='center'|40 '''@'''
|align='center'|41 '''A'''
|align='center'|42 '''B'''
|align='center'|43 '''C'''
|align='center'|44 '''D'''
|align='center'|45 '''E'''
|align='center'|46 '''F'''
|align='center'|47 '''G'''
|align='center'|48 '''H'''
|align='center'|49 '''I'''
|align='center'|4A '''J'''
|align='center'|4B '''K'''
|align='center'|4C '''L'''
|align='center'|4D '''M'''
|align='center'|4E '''N'''
|align='center'|4F '''O'''

|-
!5…
|align='center'|50 '''P'''
|align='center'|51 '''Q'''
|align='center'|52 '''R'''
|align='center'|53 '''S'''
|align='center'|54 '''T'''
|align='center'|55 '''U'''
|align='center'|56 '''V'''
|align='center'|57 '''W'''
|align='center'|58 '''X'''
|align='center'|59 '''Y'''
|align='center'|5A '''Z'''
|align='center'|5B '''['''
|align='center'|5C '''\'''
|align='center'|5D ''']'''
|align='center'|5E '''^'''
|align='center'|5F '''_'''

|-
!6…
|align='center'|60 '''`'''
|align='center'|61 '''a'''
|align='center'|62 '''b'''
|align='center'|63 '''c'''
|align='center'|64 '''d'''
|align='center'|65 '''e'''
|align='center'|66 '''f'''
|align='center'|67 '''g'''
|align='center'|68 '''h'''
|align='center'|69 '''i'''
|align='center'|6A '''j'''
|align='center'|6B '''k'''
|align='center'|6C '''l'''
|align='center'|6D '''m'''
|align='center'|6E '''n'''
|align='center'|6F '''o'''

|-
!7…
|align='center'|70 '''p'''
|align='center'|71 '''q'''
|align='center'|72 '''r'''
|align='center'|73 '''s'''
|align='center'|74 '''t'''
|align='center'|75 '''u'''
|align='center'|76 '''v'''
|align='center'|77 '''w'''
|align='center'|78 '''x'''
|align='center'|79 '''y'''
|align='center'|7A '''z'''
|align='center'|7B '''{'''
|align='center'|7C '''|'''
|align='center'|7D '''}'''
|align='center'|7E '''~'''
|align='center' style='background: #d0e0d0'|7F '''�'''

|-
!8…
|align='center' style='background: #c0ffc0'|80 '''Ň'''
|align='center' style='background: #c0ffc0'|81 '''Ś'''
|align='center' style='background: #c0ffc0'|82 '''Ć'''
|align='center' style='background: #c0ffc0'|83 '''Ż'''
|align='center' style='background: #c0ffc0'|84 '''Ź'''
|align='center' style='background: #c0ffc0'|85 '''Ŝ'''
|align='center' style='background: #c0ffc0'|86 '''Ĉ'''
|align='center' style='background: #c0ffc0'|87 '''Ẑ'''
|align='center' style='background: #c0ffc0'|88 '''Ô''' [note]
|align='center' style='background: #c0ffc0'|89 '''Ŕ'''
|align='center' style='background: #c0ffc0'|8A '''Ǔ'''
|align='center' style='background: #c0ffc0'|8B '''Ă'''
|align='center' style='background: #c0ffc0'|8C '''Ń'''
|align='center' style='background: #80f080'|8D '''Ș'''
|align='center' style='background: #80f080'|8E '''Ț'''
|align='center' style='background: #d0e0d0'|8F '''�'''

|-
!9…
|align='center' style='background: #80f080'|90 '''đ'''
|align='center' style='background: #c0ffc0'|91 '''ś'''
|align='center' style='background: #c0ffc0'|92 '''ć'''
|align='center' style='background: #c0ffc0'|93 '''ż'''
|align='center' style='background: #c0ffc0'|94 '''ź'''
|align='center' style='background: #c0ffc0'|95 '''ŝ'''
|align='center' style='background: #c0ffc0'|96 '''ĉ'''
|align='center' style='background: #c0ffc0'|97 '''ẑ'''
|align='center' style='background: #c0ffc0'|98 '''ô''' [note]
|align='center' style='background: #c0ffc0'|99 '''ŕ'''
|align='center' style='background: #c0ffc0'|9A '''ǔ'''
|align='center' style='background: #c0ffc0'|9B '''ă'''
|align='center' style='background: #c0ffc0'|9C '''ń'''
|align='center' style='background: #80f080'|9D '''ș'''
|align='center' style='background: #80f080'|9E '''ț'''
|align='center' style='background: #d0e0d0'|9F '''�'''

|-
!A…
|align='center'|A0 '''[https://secure.wikimedia.org/wikipedia/en/wiki/Non-breaking_space NBSP]'''
|align='center' style='background: #d0d0f0'|A1 '''ň''' (¡)'''
|align='center' style='background: #d0d0f0'|A2 '''Ű''' (¢)'''
|align='center' style='background: #d0d0f0'|A3 '''ě''' (£)'''
|align='center' style='background: #d0d0f0'|A4 '''ű''' (¤)'''
|align='center' style='background: #d0d0f0'|A5 '''Ě''' (¥)'''
|align='center' style='background: #d0d0f0'|A6 '''Š''' (¦)'''
|align='center'|A7 '''§'''
|align='center' style='background: #d0d0f0'|A8 '''š''' (¨)'''
|align='center' style='background: #d0d0f0'|A9 '''Ů''' (©)'''
|align='center' style='background: #d0d0f0'|AA '''Ą''' (ª)'''
|align='center' style='background: #d0d0f0'|AB '''Ę''' («)'''
|align='center' style='background: #d0d0f0'|AC '''Č''' (¬)'''
|align='center'|AD '''[https://secure.wikimedia.org/wikipedia/en/wiki/Soft_hyphen SHY]'''
|align='center' style='background: #d0d0f0'|AE '''č''' (®)'''
|align='center' style='background: #d0d0f0'|AF '''ů''' (¯)'''

|-
!B…
|align='center' style='background: #d0d0f0'|B0 '''Ő''' (°)'''
|align='center' style='background: #d0d0f0'|B1 '''Ł''' (±)'''
|align='center' style='background: #d0d0f0'|B2 '''Ť''' (²)'''
|align='center' style='background: #d0d0f0'|B3 '''Ď''' (³)'''
|align='center' style='background: #d0d0f0'|B4 '''Ž''' (´)'''
|align='center' style='background: #d0d0f0'|B5 '''ł''' (µ)'''
|align='center' style='background: #d0d0f0'|B6 '''ť''' (¶)'''
|align='center' style='background: #d0d0f0'|B7 '''ď''' (·)'''
|align='center' style='background: #d0d0f0'|B8 '''ž''' (¸)'''
|align='center' style='background: #d0d0f0'|B9 '''ő''' (¹)'''
|align='center' style='background: #d0d0f0'|BA '''ą''' (º)'''
|align='center' style='background: #d0d0f0'|BB '''ę''' (»)'''
|align='center' style='background: #d0d0f0'|BC '''Œ''' (¼)'''
|align='center' style='background: #d0d0f0'|BD '''œ''' (½)'''
|align='center' style='background: #d0d0f0'|BE '''Ÿ''' (¾)'''
|align='center'|BF '''¿'''

|-
!C…
|align='center'|C0 '''À'''
|align='center'|C1 '''Á'''
|align='center'|C2 '''Â'''
|align='center'|C3 '''Ã'''
|align='center'|C4 '''Ä'''
|align='center'|C5 '''Å'''
|align='center'|C6 '''Æ'''
|align='center'|C7 '''Ç'''
|align='center'|C8 '''È'''
|align='center'|C9 '''É'''
|align='center'|CA '''Ê'''
|align='center'|CB '''Ë'''
|align='center'|CC '''Ì'''
|align='center'|CD '''Í'''
|align='center'|CE '''Î'''
|align='center'|CF '''Ï'''

|-
!D…
|align='center'|D0 '''Ð'''
|align='center'|D1 '''Ñ'''
|align='center'|D2 '''Ò'''
|align='center'|D3 '''Ó'''
|align='center'|D4 '''Ô'''
|align='center'|D5 '''Õ'''
|align='center'|D6 '''Ö'''
|align='center' style='background: #d0d0f0'|D7 '''Ř''' (×)'''
|align='center'|D8 '''Ø'''
|align='center'|D9 '''Ù'''
|align='center'|DA '''Ú'''
|align='center'|DB '''Û'''
|align='center'|DC '''Ü'''
|align='center'|DD '''Ý'''
|align='center'|DE '''Þ'''
|align='center'|DF '''ß'''

|-
!E…
|align='center'|E0 '''à'''
|align='center'|E1 '''á'''
|align='center'|E2 '''â'''
|align='center'|E3 '''ã'''
|align='center'|E4 '''ä'''
|align='center'|E5 '''å'''
|align='center'|E6 '''æ'''
|align='center'|E7 '''ç'''
|align='center'|E8 '''è'''
|align='center'|E9 '''é'''
|align='center'|EA '''ê'''
|align='center'|EB '''ë'''
|align='center'|EC '''ì'''
|align='center'|ED '''í'''
|align='center'|EE '''î'''
|align='center'|EF '''ï'''

|-
!F…
|align='center'|F0 '''ð'''
|align='center'|F1 '''ñ'''
|align='center'|F2 '''ò'''
|align='center'|F3 '''ó'''
|align='center'|F4 '''ô'''
|align='center'|F5 '''õ'''
|align='center'|F6 '''ö'''
|align='center' style='background: #d0d0f0'|F7 '''ř''' (÷)'''
|align='center'|F8 '''ø'''
|align='center'|F9 '''ù'''
|align='center'|FA '''ú'''
|align='center'|FB '''û'''
|align='center'|FC '''ü'''
|align='center'|FD '''ý'''
|align='center'|FE '''þ'''
|align='center'|FF '''ÿ'''

|}

[note] As discussed [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/&do=findComment&comment=494855 here], the TDM char set has a redundant treatment of 2 characters:

* Ô appears at 0x88 and 0xD4
* ô appears at 0x98 and 0xF4

Planned for TDM 2.13, the redundancy can be removed and these new characters (from ISO-8859-3) introduced:

* Ğ appears at 0x88
* ğ appears at 0x98

For a mapping of these 256 codepoints to Unicode U+NNNN values and formal names, download 'TDM 8859-Style Font Map to Unicode-16.txt':

* [https://drive.google.com/file/d/1wLEtuFvnrZ-WHK8ign8i3diIXZdriZ4F/view?usp=sharing for TDM 2.13]
* [https://drive.google.com/file/d/1UAz9jSZpT_j33STP3So_Re8JWa8QuAmz/view?usp=sharing for TDM 2.12 and earlier]

Each of these files (by Geep, 2024) is in a standardized format so that it can also be imported into font design programs like FontForge as a custom 256-position map. In the comments, there is additional information about:
* ISO 8859-x sourcing of each character.
* alternative representations of some European and control characters.

=== Russian ===

Characters conform to the [https://en.wikipedia.org/wiki/Win-1251 WIN-1251 native encoding, shown in the Wikipedia article]. Exception: the character '''0xFF''' (я) is mapped to '''0xB6''' upon loading. Therefore any Russian font must contain я at the place 0xB6.

=== Asian Languages (Korean, Chinese, Japanese) ===

The original D3 had support for these languages, so it might be possible to add them to TDM, too. At the moment, however, we lack the fonts and translators. Also, writing from right-to-left (Hebrew) or top-down (Japanese) might be tricky or outright impossible in our GUI without more work in the C++ code. Plus, these languages use more than 256 different characters, and an 8 bit table will not hold these.

== European Character Implementation ==
=== Priority Early-On - the "Top 50" ===

Some of the special characters are used more often than others. Here is a statistic over the entire string set of the TDM core, from TDM v1.08, showing the top 50 most-used characters (excluding a-z, 0-9 and russian characters):

{|class="wikitable" border=1 style="border-collapse: collapse; font-size: 85%" cellspacing=0 cellpadding=2

|-
|Rank
|Occurances
|Letter
|Remarks
|Rank
|Occurances
|Letter
|Remarks

|-
|1
|í
|715
|
|25
|ć
|67
|

|-
|2
|é
|674
|
|26
|è
|65
|

|-
|3
|á
|524
|
|27
|ú
|56
|

|-
|4
|ø
|303
|Danish
|28
|ê
|52
|

|-
|5
|č
|288
|
|29
|ö
|48
|German

|-
|6
|ó
|283
|
|30
|É
|46
|

|-
|7
|ü
|270
|German
|31
|ñ
|37
|

|-
|8
|ł
|203
|Polish
|32
|õ
|32
|

|-
|9
|æ
|200
|Danish
|33
|ń
|26
|

|-
|10
|ě
|182
|
|34
|Ł
|24
|

|-
|11
|ř
|175
|Czech
|35
|Š
|21
|

|-
|12
|ã
|168
|
|36
|â
|21
|

|-
|13
|ž
|148
|Czech
|37
|ź
|20
|

|-
|14
|ý
|142
|
|38
|ß
|18
|German

|-
|15
|ę
|141
|
|39
|Ó
|18
|

|-
|16
|ą
|140
|
|40
|ň
|15
|

|-
|17
|ż
|119
|
|41
|Ú
|15
|

|-
|18
|å
|109
|Danish
|42
|Á
|13
|

|-
|19
|š
|99
|
|43
|î
|12
|

|-
|20
|ś
|97
|
|44
|ť
|11
|

|-
|21
|ç
|91
|
|45
|ô
|9
|

|-
|22
|ä
|86
|German
|46
|Ž
|8
|

|-
|23
|à
|83
|
|47
|Ż
|7
|

|-
|24
|ů
|77
|
|48
|Č
|7
|

|-
|25
|ć
|67
|
|49
|ù
|6
|

|}

Although ö, ä and ü do not appear that often, with only these and Ü, Ö, Ä and ß, the entire German language works. So adding these letters to the fonts is quite important.

Preferably, all foreign letters would be added to the fonts (see [[Font Patcher]] or [[Refont]]). However, if time permits only adding a few, '''í''' would be more important than, say, '''ô'''.

It is commonplace for missing accented letters to be redirected in the .dat file to the corresponding unaccented base letter.

=== Coverage Expansion & Remaining Limitations ===

By 2014, all the system (e.g., main menu) fonts (Carleton, Carleton_condensed, Stone in sizes 24pt and 48pt; Mason and Mason_glow in 48pt) had good coverage of the "Top 50" and beyond, although not all 256 codepoints.
This was confirmed more specifically in 2024, as part of an [https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/ Analysis of 2.12 Fonts]. This analysis indicated that, unlike the system fonts, the FM fonts generally did not provide specific glyphs beyond ASCII.

In 2024, Stone 24pt, important for subtitles and a number of readables, was further extended to cover all 256 codepoints. This was tested with TDM 2.13[betas] and released with 2.14. Similar Stone 48pt and Carleton 24pt improvements are planned for TDM 2.15.

[[Category:Fonts]]

{{i18n}}

Rebuild all lang Program

2026-01-21T19:29:52Z

Geep: Add ending tags

''by Geep, 2026''
==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use '''rebuild_all_lang'''. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
- deciding in advance which *.lang files are the current directory
- if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As an example, the program distribution includes a typical stock preamble.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are always processed in the order shown. If a particular *.lang is missing, that is handled quietly, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

==== Downloads ====
v 1.0 Source Code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code: a .cpp and .sln file]

Example preamble files (rename to preamble_utf8.txt to use):
* [https://drive.google.com/file/d/1bOWXv8Ju1DktaNYe2M8Bo-V7zAg2bNJ9/view?usp=sharing preamble_utf8[traditional<nowiki>]</nowiki>.txt]
* [https://drive.google.com/file/d/1QKJvG6FoAzuI7njO5fnOQCgwbXQdWqQe/view?usp=sharing preamble_utf8[modern for FM<nowiki>]</nowiki>.txt]
==== See Also ====
* [[Gen_Lang_Programs]]

{{i18n}} {{editing}}

Rebuild all lang Program

2026-01-21T19:27:08Z

Geep: Tweak "Downloads" & "See Also"

''by Geep, 2026''
==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use '''rebuild_all_lang'''. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
- deciding in advance which *.lang files are the current directory
- if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As an example, the program distribution includes a typical stock preamble.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are always processed in the order shown. If a particular *.lang is missing, that is handled quietly, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

==== Downloads ====
v 1.0 Source Code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code: a .cpp and .sln file]

Example preamble files (rename to preamble_utf8.txt to use):
* [https://drive.google.com/file/d/1bOWXv8Ju1DktaNYe2M8Bo-V7zAg2bNJ9/view?usp=sharing preamble_utf8[traditional<nowiki>]</nowiki>.txt]
* [https://drive.google.com/file/d/1QKJvG6FoAzuI7njO5fnOQCgwbXQdWqQe/view?usp=sharing preamble_utf8[modern for FM<nowiki>]</nowiki>.txt]
==== See Also ====
* [[Gen_Lang_Programs]]

Rebuild all lang Program

2026-01-21T19:19:33Z

Geep: /* Downloads */ added links

''by Geep, 2026''
==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use '''rebuild_all_lang'''. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
- deciding in advance which *.lang files are the current directory
- if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As an example, the program distribution includes a typical stock preamble.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are always processed in the order shown. If a particular *.lang is missing, that is handled quietly, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

==== Downloads ====
Source code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
* [https://drive.google.com/file/d/1kKunDZfVcolZgU4xMsYIpWc5VQgjd3-_/view?usp=sharing Windows executable rebuild_all_lang.exe]
* [https://drive.google.com/file/d/1sNbWZRznhmgUeGJR8GXK6uiMGAstTusY/view?usp=sharing rebuilt_all_lang.zip - source code: a .cpp and .sln file]

Example preamble files (rename to preamble_utf8.txt to use):
* [https://drive.google.com/file/d/1bOWXv8Ju1DktaNYe2M8Bo-V7zAg2bNJ9/view?usp=sharing preamble_utf8[traditional<nowiki>]</nowiki>.txt]
* [https://drive.google.com/file/d/1QKJvG6FoAzuI7njO5fnOQCgwbXQdWqQe/view?usp=sharing preamble_utf8[modern for FM<nowiki>]</nowiki>.txt]
==== See Also ====
[COMING SOON]

Rebuild all lang Program

2026-01-20T18:55:36Z

Geep: create article

''by Geep, 2026''
==== Introduction ====
Ordinarily, an FM that has been internationalized has a UTF8 "all.lang" text file, from which "*.lang" files in various 8-bit ISO-8859-x (or Windows) encodings were generated and distributed within the "strings" folder.

Sometimes, an attempt is made to improve translations, or extend them to additional languages. The ideal way is to alter content in all.lang, then regenerate the *.lang files (e.g., with gen_lang_plus). This regeneration could be for every language section specified in all.lang, or more selectively, just the ones for languages newly added or with changed content.

Suppose "all.lang" was not distributed with the FM. The original FM author may be able to provide it, or you can ask about it being in some TDM SVN repo.

If those routes fail, you can fabricate a replacement all.lang from the *.lang files. Note that the latter are stripped of helpful comments, including grouping header lines, often found in the original all.lang. So this approach is driven by necessity.

One way that fabrication can be done is first make a new partial all.lang from the existing english.lang file (which being in ASCII, can be viewed as also UTF8), Then add new language sections in UTF8 form. Regenerate just those *.lang files, while retaining older unchanged *.lang files. Each new UTF8 language section can be -
* typed from scratch, while consulting the ISO-8859-x version.
* possibly generated using some third-party ISO to UTF8 translator tool.

Or, as a convenience, use rebuild_all_lang. When run from within a give folder (e.g., "strings"), it will take every *.lang it finds (starting with english.lang), convert it from that language's ISO to UTF8, and basically glue them together into the required form.

==== Usage and Example ====
The Windows command-line program rebuild_all_lang is a simple C++ utility that takes no parameters, and if successful generates "all.lang" in the current directory. Control it by -
- deciding in advance which *.lang files are the current directory
- if you want the generated file to embed a preamble, you can provide it as a file named "preamble_utf8.txt" in the same directory. This is optional. As an example, the program distribution includes a typical stock preamble.

A typical output to console is:

Running rebuild_all_lang, v. 1.0
Note: Did not find an optional preamble file preamble_utf8.txt
Processing...
English
German
French
Italian
Spanish
Polish
Romanian
Russian
Portuguese
Czech
Hungarian
Slovak
Swedish
Danish
Dutch
Turkish
Catalan
Contents of *.lang files were converted successfully to UTF-8 and merged into new 'all.lang'.

Languages are always processed in the order shown. If a particular *.lang is missing, that is handled quietly, and that section is not added to all.lang.

At the start of all.lang, typical text is...

// Rebuilt all.lang file - created by rebuild_all_lang v. 1.0
// Strings in each section in same order as in *.lang, but converted from various iso-8859s encodings to UTF8.

// Note - did not find an optional file preamble_utf8.txt with preamble comments to place here.

{
[English]
// Sourced from english.lang of 2025-07-16T16:08:26+00:00, whose first line was...
// String table - english (iso-8859-1) - created on 2025-07-16T16:08:26Z with gen_lang_plus v. 1.1
"#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n"
....

Within each language section - like [English] here - some variant of the first two commented lines are always generated. As you see, the "// Sourced from..." line is followed by the first line copied from the *.lang file. In this example, the comments show the external file modification datetime, and then the datetime written at generation time. The latter will not always be present, depending upon creation method.

==== Details ====
As required, the generated all.lang text file has Linux linebreaks (e.g., LF instead of CRFL), independent of linebreak form in input files *.lang or preamble_UTF8.txt

If all.lang already exists, you will see...

Running rebuild_all_lang, v. 1.0
File 'all.lang' already exists.
Continue and overwrite it? [y/n]

If you indicate "n" for "no", the program quits with message "Bye".

This program has some minimal file I/O and conversion error checking, with reporting to console. It is not thought necessary to do character-level checking of the UTF8 results against characters supported by TDM's character map... such checking is better done elsewhere. This is a simple program. (One could imagine a more elaborate version that would, say, allow english.lang to be annotated with comments (e.g., to group lines into subsections). And then reorder lines within the non-English language sections to match, embedding those same annotations.)

==== Download ====
[COMING SOON]
The distribution includes an example stock "preamble_utf8.txt" file.
Source code: This C++ v20 program was developed under Windows 11 with VS 2022 Community Edition (updated through 2025).
==== See Also ====
[COMING SOON]

Subtitles

2026-01-17T18:20:01Z

Geep: /* internationalization */ section added

Support for subtitles (or closed captions) was added in TDM 2.10.

=== What the player sees ===
In 2.10+, the player can control subtitle visualization under Settings/Audio/Subtitles, which takes one of these values:
* Story - display only story-related subtitles
* On - display subtitles for all speech
* Off - disable subtitles
"Story" is the default. If "On" is chosen, story and non-story speech subtitles (like for AI "barks") appear.

Each subtitle has an implicit or explicit start and end time relative to its audio clip. To handle multiple overlapping sounds, the text is not interwoven; instead, there are 3 separate, non-overlapping fields, stacked in the lower part of the screen. When a subtitle is shown, it is as white text on a translucent field-rectangle background. A text line that is too long is wrapped to two lines.

One immediate purpose for TDM's subtitles is to provide English captions for English audio. This will assist understanding of accented dialog for those who are hearing-impaired or whose English is less fluent. (In theory, subtitles could be relied upon to play an FM silently, but the lack of audio positional and distance cues, e.g., for footsteps, would be detrimental.)

As for translation, i.e., subtitles shown in other TDM-supported languages, the current system provides an important and usable building block. An FM author could employ it to provide "story" subtitles in a particular language other than English. Furthermore, a non-TDM site for a specific non-English audience - one that hosts full ports of TDM and its FMs - could create its own subtitle files in the target language. Other ideas for future capabilities, such as easy switching among multiple subtitle languages, are [https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/ under discussion].

=== Rollout so far ===
''As of 2.11''

The "Subtitles" setting affects the CVar "cv_tdm_subtitles", as follows:
* Story --> 1 --- show only story-relevant
* On --> 2 --- show all speech
* Off --> 0 --- hide all

There is an additional cv_tdm_subtitles value, 3. It means "show everything", including additional subtitles for sound effects. No core sound effect subtitles are provided yet.

Subtitles are not generated on the fly. They are pre-encoded into game files (as detailed below), and this will take human effort over time. "Story" subtitles are chiefly associated with custom sound files and typically the responsibility of the FM author. Conversely, subtitles for AI standard speech phrases (as well as standard sound effects) are seen as mainly core resources.

For the FMs included in the standard distribution, "Tears of Saint Lucia" (in 2.10) and "A New Job" (planned in 2.11) have "Story" speech English subtitles.

Non-story speech (as of 2.10) is limited to a dozen phrases of the "Cynic" voice, used by some attacking guards. Since this is part of the core distribution, these English subtitles become available to existing games automatically. [https://forums.thedarkmod.com/index.php?/topic/21740-english-subtitles-for-ai-barks/ A project to expand this coverage for 2.12] has been started.

See also the section "displaying text with extended duration (new for 2.12)" below.

=== How it works ===

Subtitles work on a very low level: where the engine manages sound samples and sound channels.
This approach allows to reliably add subtitles for sounds of any kind, but has some downsides too: the system does '''not''' know anything at all about entities, spawnargs, scripts, and other gameplay stuff.
The system allows to assign chunks of text directly to sound samples (which are usually .ogg and .wav files), so that when a sound sample is played, the assigned text is shown on the screen.

=== Subtitles decls ===

The assignment of text to sound samples is specified in a new type of decl files. These files must:
# be in '''subtitles''' directory,
# have '''.subs''' extension,
# contain declarations of type '''subtitles'''.
For comparison, materials are another type of decls, which must be in <tt>materials</tt> directory, in files with <tt>.mtr</tt> extension, and be of type <tt>material</tt>.

To avoid any conflicts between core game and missions, FM authors should follow the conventions:
# Names of subtitles decl files must start with '''fm_''', e.g.: <tt>fm_conversations.subs</tt>
# Names of declarations must start with '''fm_''' too, e.g.: <tt>fm_paul_intro_convo</tt>

Here is an example of <tt>fm_conversations.subs</tt> contents:

//note: comments work as they normally do

subtitles fm_intro_convo {
verbosity story
inline "sound/voices/paul/sound1.ogg" "My name is Paul, and I'm a city guard."
inline "sound/voices/bjorn/sound2.ogg" "Welcome to Anonymous City Guards! Call me Bjorn."
inline "sound/voices/paul/sound3.ogg" "I started cutting thieves' throats when I was 17..."
inline "sound/voices/paul/sound4.ogg" "... and now I cannot stop doing that!"

verbosity effect
inline "sound/voices/paul/sound5.ogg" "(starts weeping)"

verbosity story
inline "sound/voices/bjorn/sound6.ogg" "Calm down, Paul! We all were in your shoes!"
inline "sound/voices/bjorn/sound7.ogg" "Let us first watch an educational video about the harm from cutting throats."

srt "sound/voices/bjorn/sound8_long.ogg" "sound/voices/bjorn/sound8_long.srt"
}

subtitles fm_briefing {
verbosity story
srt "fromVideo video/sts_briefing_intro" "video/briefing/briefing.srt"
}

==== displayed text ====

There are two ways to specify subtitle text: inline and srt-based.

'''inline''' command is followed by a name of sound sample and the text to be displayed while it is being played.
In this case, the text is written straight in the decl file, and it is displayed for the whole duration of the sound sample.
This way is convenient for short sounds, which are the majority of sound samples, including phrases of a conversation. A "\n" can be embedded in the text to force a line break.

'''srt''' command is followed by paths to a sound sample and its .srt file, typically with matching filenames. This method, while more complicated than inline, has the flexibility to support a long sound file that needs multiple sequential subtitles, such as the sound sample of a briefing video. An .srt file, in "SubRip" format, is usually placed either with its sound file or in a "subtitles" folder. It contains a sequence of text messages to show during the sound sample, each with start and end HH:MM:SS,sss timestamps within the sample's timeline. For example:
1
00:00:03,612 --> 00:00:10,376
Bugger me!
Something's wrong with this crystal ball.

2
00:00:25,336 --> 00:00:28,167
Ah! Here we go.
Creating .srt files is best done with third-party AV software, not writing them manually. For TDM, files must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. While implementations of the [https://en.wikipedia.org/wiki/Subrip#SubRip_file_format "SubRip" file format] often include HTML-style markups for font attributes like bold or italics, these are not possible for TDM. What TDM ''does'' have is limited primary-color font markup, applicable to inline and srt subtitles; see [[Text_Decals_for_Signs_etc.#Signs_with_Illuminated_Colored_Letters | Signs_with_Illuminated_Colored_Letters]] for details.

==== displaying text with extended duration (new for 2.12) ====

A TDM inline subtitle appears on screen at the start of its audio clip. By convention, this is true for srt as well; the first message starts at time 00:00:00,000.

Under 2.10/2.11, a subtitle goes away when its audio clip ends. For srt, this is true even if a timestamp specifies a value beyond the audio clip duration.

Starting with 2.12, both automatic and manual extensions are provided.

'''For inline subtitles.''' Automatically, durations are extended by 0.2 seconds past the clip end. This matches the 0.2 second pause automatically put in between each voice clip in the Conversation object, so as to show such subtitles without a visual gap. This degree of extension is considered imperceptable. In addition, 1.0 second is now the minimum duration of an inline subtitle, as widely recommended for captioning. (These extensions apply to all subtitles, not just Conversation.)

For any particular "inline" command, the 0.2 second value can be overridden (e.g., with a larger value) by an additional trailing parameter, with syntax of either:

-durationExtend ''<positive value>''
-dx ''<positive value>''

Example:
inline "sound/voices/bjorn/sound7.ogg" "Let us first watch an educational video about the harm from cutting throats." -dx 0.45
Manual extension may be needed with particularly fast talking (i.e., high presentation rate, as expressed in characters-per-second or words-per-minute). Conversely, to avoid irritating the reader with noticeably lagging subtitles, use manual extension sparingly. In particular, don't be keen to go longer than 1/2 second.

There is a sanity upper limit of 5.0 seconds on the extension. So overall, the calculated duration is:
duration = max(c + 0.2, 1.0) ''if x not defined''
duration = min(max(c + x, 1.0), c + 5.0) ''if x defined''
where c is the clip length, and x is the -dx value

'''For srt subtitles.''' The automatic extensions provided for inline do not apply to srt. Instead, the srt timestamp values can now extend beyond the clip end.

It is the srt author's responsibility to apply best-practices such as:
* Start the first message at time 0
* Avoid messages less than 1 second duration
* Try to cut messages between sentences, or at other vocal pauses
* Don't overlap messages in time
* Usually, messages are abutted; sometimes, significant time gaps are appropriate
* Avoid ending the last message much beyond the clip length (analogous to -dx considerations)
* While such a duration extension directly benefits the final message, it is sometimes possible to "distribute the benefit" to an earlier message by small shifts in message breaks.

==== internationalization ====

As mentioned above, a mechanism for support of translations, e.g., use of #str IDs, has not been developed. As of TDM 2.14 [alpha], one pre-requisite for European languages exists: build-out of the font used for subtitles, "english" Stone 24pt, to include complete coverage of all 256 characters in the TDM character map.

==== sound sample ====

In order to specify sound sample, write path to the file the same way you do e.g. in sound shaders.

One complicated case is when you have an [[Cutscene_video_with_FFmpeg#Play_video_with_sound|FFmpeg-based video with embedded sound]].
In this case write material name, prepended with '''fromVideo''' keyword and space, just like you do in the sound shader.
See <tt>fm_briefing</tt> in the example above.

==== verbosity ====

Currently there are three verbosity levels for subtitles:

* '''story''': This level should be applied to all story-related subtitles, everything that player should absolutely notice and understand.
* '''speech''': This is for subtitles of speech which is usually of little interest to the player, or is repeated too often. For instance, regular AI barks (e.g. "I'll get ya!") belong here.
* '''effect''': This level is reserved for non-speech subtitles which have little interest to the player, like "(bang)" or "(ding)", etc.

It is not yet clear how exactly these levels will be used in the long term. For now:

# By default, players only see <tt>story</tt>-level subtitles, although they can enable the other two categories in settings, or disable subtitles entirely.
# It is expected that almost all FM-specific subtitles get into <tt>story</tt> category. The other two exist mostly for core TDM sounds, which include a lot of AI barks (<tt>speech</tt> level) and trivial sound effects like arrow hit (<tt>effect</tt> level).

Every subtitles declaration must start with '''verbosity''' command.
This command applies to all the subsequent commands, until the other <tt>verbosity</tt> is met or declaration ends (whichever happens first).
For instance, all subtitles have <tt>story</tt> verbosity level in the example above, except for the "(starts weeping)" text, which has <tt>effect</tt> verbosity.

==== include ====

While the engine parses all declarations that are present in the files, the subtitles system only uses one subtitles decl named <tt>tdm_root</tt>. ''Include'' commands are used in order to put other subtitle decls into it. (The <tt>tdm_root</tt> decl is in file <tt>tdm_root.subs</tt>. As of TDM 2.11, this file, and all core non-game-specific tdm_*.subs, can be found in tdm_sound_vocals_decls01.pk4/subtitles/. An ''fm_root.subs'' file exists there, whose stub fm_root decl is over-ridden by your FM's fm_root as described next.)

'''include''' command has one argument: the name of the subtitles decl to be included. Note that it is the name of the decl, not the name of the file which contains it! Included decl can in turn include other decls.

FM-specific subtitles are always included from the decl named '''fm_root''', which must be in the '''fm_root.subs''' file. For instance, the contents of the <tt>fm_conversations.subs</tt> file from the example above will have no effect until we add the file <tt>fm_root.subs</tt> with contents:

/**
* This file should be overridden in order to provide mission-specific subtitles.
* When doing so, please follow the conventions:
* 1) The root decl is called "fm_root" and is located in file "fm_root.subs".
* 2) All other subtitle decls start with "fm_" prefix and are located in files starting with "fm_".
*/

subtitles fm_root {
include "fm_intro_convo"
include "fm_briefing"
include "fm_much_later" // points to the decl below
}

// Decls and their "inline"/"srt" commands can be in the fm_root.subs file, not just in other .subs files:
subtitles fm_much_later {
verbosity story
inline "sound/voices/paul/sound14.ogg" "Where did I put that knife sharpener?"
}

Notice that one decl can be used to do any number of subtitle assignments, so it is not necessary to have many decls and decl files. The easiest way to do FM-specific subtitles is to have one <tt>fm_root.subs</tt> file with one <tt>fm_root</tt> decl, and specify all your subtitles right there. Splitting subtitles across decls and files is entirely optional and can be used for grouping subtitles. It was added mainly for core TDM sounds: there are several thousands of them, so keeping all subtitles in a single file can become a headache quickly.

=== Output ===

The subtitles which should be displayed right now are provided to GUI code as '''gui::subtitleN''' variables, where N ranges from 0 to 3 (although only 0 to 2 will be made visible by the standard GUI scripting described next).
GUI scripts display these variables as non-overlapping text messages. Given a logical screen height of 480, each of the 3 fields is 45 units high. N = 0 is the lowest, at Y-origin 400; 1 at 350; 2 at 300.
The responsible code is located in <tt>tdm_subtitles_common.gui</tt> file, and is already used in several places:
* in the following states of the main menu: briefing, briefing video, and debriefing video
* in the always-on GUI overlay during gameplay

For example, here is how it is used in <tt>mainmenu_briefing.gui</tt>:

//note: each include of tdm_subtitles_common must have different name prefix!
#define SUBTITLES_NAMEPREFIX Briefing
#include "guis/tdm_subtitles_common.gui"

Usually, you don't need to do anything about it. However, this information can be relevant if you write some custom GUI and want to see subtitles there.

Note: it is not clear yet which kind of customization is necessary for the subtitles GUI.
If you have any ideas, please share them on [https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/ forums].

{{GUI}}

Mason Font

2025-10-21T22:05:06Z

Geep: Add new section: 2025 Improvements to Russian [Proposed for TDM 2.14]

''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). The styling features top-alignment of characters, achieved by giving capital letters a higher-than-normal baseline. 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 [https://forums.thedarkmod.com/index.php?/topic/13825-menu-concerns-for-108/ "Menu concerns for 1.08"] and Tels' "Translating the TDM GUI" thread, particularly [https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/14/#findComment-274467 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
[https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/5/#findComment-262661 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' [http://bloodgate.com/mirrors/tdm/pub/tdm_i18n.zip 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 [https://forums.thedarkmod.com/index.php?/topic/19129-menu-update/#comment-412921 "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

== 2025 Improvements to Russian [Proposed for TDM 2.14] ==
''For more about this project by kalinovka and Geep, including motivations, approaches, and resulting screenshots, test FMs and details of individual characters,, see the "Font localization" thread, particularly this [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization/#comment-501602 this post with links and screenshots].''

=== Coverage, Appearance, and Bitmaps ===

Mason /russian/ was missing a number of alphabetic glyphs for TDM-defined Cyrillic characters. This upgrade corrected that, so that Mason can be used not just for the main menu system, but in-game (albeit with still only 48pt distributed). When easy to do, some characters also got crisper glyph rendering or improved spacing. (Some characters will remain soft-edged or not-ideally spaced.)

The main approach was to first replace the /russian/ Mason DDS set with the TDM 2.13 /english/ Mason set (with corresponding DAT file changes), then - as fill-in - add newly-generated DDS from a "Lora Regular" font. While less stylish, Lora (in adjusted point sizes) is adequate to "pass" as Mason 48pt. The original "Mason Alternate" TTF source did not include Cyrillic characters.

Specifically, the DDS set, distributed under "tdm_fonts01/dds/fonts/russian/mason", became as follows.
Copied from the TDM 2.13 /english/ set (replacing the 2.13 /russian/ set), with Jan. 17, 2021 file dates:

* masonalternate_0_48.dds
* masonalternate_1_48.dds
* masonalternate_2_48.dds
* masonalternate_3_48.dds
* masonalternate_4_48.dds
* masonalternate_5_48.dds

Newly generated lower-case and symbols for /russian/, with 2025 file dates:

* lora45_as_mason_6_48.dds
* lora45_as_mason_7_48.dds

Newly generated upper-case for /russian/, with 2025 file dates:

* lora54_as_mason_8_48.dds
* lora54_as_mason_9_48.dds
* lora54_as_mason_10_48.dds

=== Revised DAT File ===
The contents of several DAT files were hand-merged, to reach the final DAT that mixes shaders for "Mason Alternate" & "Lora Regular" fonts.

At codepoints 0x00-7f, the TDM 2.13 Mason ''/english/'' ASCII characters appear. These render crisply, due to previous bitmap improvements: doubling of bitmap size, followed by glyph redrawing to limit anti-aliasing.

At codepoints 0x80-ff, for Cyrillic, there's a mix of:

* Cyrillic characters already existing in the Mason /english/ set (some the same glyphs as ASCII, a few the same as European, some previously hand-drawn)
* New non-capitals generated from Lora 45pt (matching the height of Mason 48pt).
* New capitals generated from Lora 54pt. Because these were generated at a larger point size, they didn’t require additional 120% DAT scaling (with its added edge-softening) to reach the target size. But they did need DAT adjustments to be top-aligned in the TDM-specific style for this font.

A few characters got additional special treatments.

=== Mason_glow ===
Finally, the /russian/ mason_glow font was also updated with a clone of these updated /russian/ Mason resources. (This differs from how /english/ glows are implemented.)

== Working with Mason Today ==
=== Improved Tools to Generate Bitmaps from TTF and to View Font Coverage ===
The 2025 Improvements to Russian included:

* Creating the [[ExportUnicodeFontToDoom3]] utility, used to generate the new Lora DDS and DAT files.
* Deploying several test FMs. The final one, testMasonLora3Way.pk4, displays the entirety of the proposed 2.14 /russian/mason font. (This is available via the "Font localization" link above. It is trivial to clone and adapt this FM to show comparable coverage for other /russian/ or /english/ fonts.)

=== 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 and datBounds v1.6 now supports mixed-sized bitmaps. See in particular [[Refont#Mason Family]].

=== 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.)

{{tutorial}} [[Category:Fonts]]

ExportUnicodeFontToDoom3

2025-09-11T21:35:55Z

Geep: Add release 1 links

ExportUnicodeFontToDoom3

2025-09-10T20:06:33Z

Geep: /* Changed Behavior */

''By Geep, 2025 [WORK IN PROGRESS]''

== Introduction ==

In 2025, kalinovka in [https://forums.thedarkmod.com/index.php?/topic/22736-font-localization Font localization] sought to extend TDM’s Mason 48pt font, used in the main menu, to include missing Cyrillic glyphs. This would allow this font to be used in an FM and still support a Russian translation.

This offshoot of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256] is a generalized response to that. The main idea to select an input TTF font that includes not just ASCII or ANSI, but offers additional Unicode characters, like Cyrillic. The program still limits output to a maximum of 256 characters, consistent with the DAT format.

To achieve this, it reads in an external human-readable "unicodeMap" file, in Unicode.org’s "Format A". This format provides a mapping from the traditional 8-bit encoding that TDM uses to the corresponding UCS (Unicode 16-bit) value. Unicode.org provides stock files for standard ISO and Windows 8-bit encodings. Of specific interest here is [https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT cp1251.txt for Cyrillic]. This requires just trivial editing for [https://wiki.thedarkmod.com/index.php?title=I18N_-_Charset TDM-specific codepoints].
As discussed below, you can further edit a unicodeMap file in advance, if you want to generate just a subset of glyphs.

== New Command Line Arguments ==

These are in-addition to those of [https://wiki.thedarkmod.com/index.php?title=ExportFontToDoom3 ExportFontToDoom3All256].

=== unicodeMap <file> ===
Example:

-unicodeMap "./Test/cp1251.txt"

You can edit the unicodeMap file in advance, to specify which particular glyphs you want to generate by suppressing unwanted glyphs, either by:

* Deleting an unwanted line (or block of lines) entirely, or
* Prepending a "#" to comment-out the line.

Also, this file format allows the Unicode value (e.g., "0x1234") to be replaced by 6 space characters, when the ISO or Windows standard leaves that character undefined.

In all 3 of those cases, every suppressed character in the output DAT file will be represented by the glyph that the font uses for U+0000. A hollow box is common.

=== startFileNumber <n> ===
When a set of TGA/DDS files are generated for a particular font size, by default the first file's name contains _0_, which increments for additional files. You can optionally specify a different 1- or 2-digit start number, e.g., "-startFileNumber 7". Why? Because...

* the file(s) you are generating are supplemental to, not replacements for, existing TGA/DDS files; and
* in this run, you are generating just one of the 3 possible font sizes (assuming each size has a different count of existing TGA/DDS files).

When you generate a supplemental set, the new DAT file has no knowledge of what's in the original set and its DAT file. You will have to interleave-edit the old and new DAT files (e.g., with reFont's REF files) to create a single DAT file spanning old and new glyphs. There may be a redundant NULL glyph in your new TGA set; just ignore it.

=== awayFromEdge <n> ===

Allows specifying in positive integer pixels (e.g., "-awayFromEdge 2") a small extra boundary at the top and left edges of the overall bitmap. This is for fonts like Mason where extra space (typically 2 pixels) is needed around every character to create a "glow variant". Routine glyph layout provides usually enough space for this except at the top and (arguably) left edges. See also the "compact" parameter.

=== compact ===
If specified (i.e, "-compact"), packs the character glyphs more closely together. Particularly recommended for 48pt fonts; it will generate roughly half the files.

Whether "compact" is specified or not, packing is controlled by simply "padding" each glyph’s bounding box. Specifically, this doesn’t change the bounding box, but adds pixel "padding" to just the right and bottom of the bounding box, a simple though asymmetric process. One reason for padding was given ExportFontToDoom3 author Grant Davies in code comments:

"Because of the way Doom 3 Indexes the texture page (using floating point numbers), it is unable to reference exact pixels – there is error. How much error, I don’t know. For this reason, the rectangles needs to be padded out."

Geep suspects that such error with the TDM engine is not really a problem. Likely some error in the past was due to editing with Q3Font and its low floating-point precision. Nevertheless, some padding is good because:

* For the Mason font, 2 pixels around each glyph are needed for "glow" effects (either done as a separate smudge font for /english/ or as a bidirection offset effect for /russian/.)
* Keeping glyphs separated improves visualization of boundaries with datBounds, and makes editing tweaks easier.

The "compact" setting restores Grant Davies' first algorithm, which just pads the bounding box by 5 pixels to the right and 5 pixels below.

Without "compact", the default is Grant Davies' second algorithm found in ExportFontToDoom3 v1.02. This likewise first pads each bounding box by 5 pixels to the right and 5 pixels below. It then further pads to make both the width and height a factor of 2; this makes 48pt quite sparse. (It is possible this improved rendering performance in 2005; not important now. Also, in practice for major fonts, much of this "factor of 2" spacing was overridden by subsequent Font Patcher work.)

=== (hirez - another possible argument) ===
''Geep: This is a future idea, but no promises on this.''

Change code to allow export of 512x512 bitmaps with larger, thus crisper glyphs. Specifically, add a new command-line option, -hirez, that would
* output 512x512 TGAs and their DAT.
* internally, double the character glyph size; so if your requested 48pt, it would make 96pt glyphs. (This is more or less how /english/ 512x512 treats its hand-made glyphs.)
* make whatever other layout & metric adjustments needed. The imageHeight and imageWidth metrics will be as if the requested 48pt size was generated, so in effect scaling down by a factor of 2 from the 96pt glyph.

== Changed Behavior ==
In ExportFontToDoom3All256, if the font title was more that 20 characters long, it would truncate it to fit in the DAT file as part of the shader names (i.e., paths to TGA files). But this threshold was wrong. Now, truncation and a warning happens if the font title is more that 17 characters long (or 16 if generated TGAs include any with a 2-digit count instead of 1-digit). If truncation occurs, the user is asked to consider using or revising the -name argument.

== Downloads ==
[links to do]

Windows binary and required archived versions of FreeType and DevIL DLLs:

ExportUnicodeFontToDoom3 Release 1 of 09-10-2025.zip

The C++ project file with source code:

ExportUnicodeFontToDoom3_source_project.zip Release 1 of 09-10-2025. This zip is ... MB, includes source & build project of archived library.

The Cyrillic coverage of Lora Regular TTF font, projected to used as Russian Mason supplement in TDM 2.14, may be viewed and font downloaded [https://www.fontsquirrel.com/fonts/lora?filter%5Bclassifications%5D%5B0%5D=serif&filter%5Blanguages%5D%5B0%5D=cyrillic#eula here].