View Issue Details

IDProjectCategoryView StatusLast Update
0002812The Dark ModCodingpublic19.02.2012 16:26
Reportertels Assigned Totels  
Status resolvedResolutionfixed 
Product VersionTDM 1.06 
Target VersionTDM 1.08Fixed in VersionTDM 1.08 
Summary0002812: Character 0xFF does not work in fonts
DescriptionThe D3 font renderer has a bug where it does not render the character 0xFF. Either it treats it as an escape, or simply forgets to go past 255 due to a one-off bug.

This effects atm only Russian, where the character is actually used for the letter "я" (in win-1251 which is the encoding used for strings/russian.lang).

Once D3 goes open source, we can have a look to fix the rendering, and possible also make it use UTF-8.
TagsNo tags attached.


related to 0002779 confirmed Translate the menu and HUD into different languages 
related to 0002811 resolvedtels Font loading does not fall back to English 




03.09.2011 14:22

reporter   ~0004016

Fixed with checkin 0004968. As a workaround we transform 0xff to 0xb6 at loading time of any lang dict. (The russian font contains the correct character at 0xb6). This way it works with any dictionary, and/or readable (when these use "#str_12345" constants, which theymust for I18N to work, anyway).

Once D3 goes open source we might revisit this and fix the GUI rendering bug(s). But for now this works.


19.02.2012 16:25

reporter   ~0004340

The bug inside the D3 code has been fixed, so character 0xFF now renders. The remapping for Russian is still in place, tho, to avoid having to patch all the russian fonts.

However, the remapping code has been reworked. The first version exchanged characters one by one, so that if you had "AB" and a table of [ A => B, B => A ], you got "BB" after the first step, and "AA" after the second step.

This was wrong, we should end up with "BA" instead. In v1.07, this was worked around by keeping a special order in the character remap tables.

For the new polish characters, however, this became impossible, so with revision #5920 this was finally fixed.

Issue History

Date Modified Username Field Change
15.07.2011 06:49 tels New Issue
15.07.2011 06:49 tels Relationship added related to 0002779
15.07.2011 06:49 tels Relationship added related to 0002811
03.09.2011 12:22 tels Target Version => TDM 1.07
03.09.2011 13:59 tels Assigned To => tels
03.09.2011 14:22 tels Note Added: 0004016
03.09.2011 14:22 tels Status new => resolved
03.09.2011 14:22 tels Fixed in Version => TDM 1.07
03.09.2011 14:22 tels Resolution open => fixed
19.02.2012 16:25 tels Note Added: 0004340
19.02.2012 16:26 tels Fixed in Version TDM 1.07 => TDM 1.08
19.02.2012 16:26 tels Target Version TDM 1.07 => TDM 1.08