🚀 go-pugleaf

Daan wrote:
> Josef Drexler wrote:
>> That's really the only place it matters.  I'm not sure how to design it
>> though.  In Linux I create my non-standard characters with the "combine"
>> key, e.g. the sequence <combine " a> becomes ä.  Something like that
>> would be workable, but won't support all needed characters.
> 
> Ehh? this works already like that in the windows version on winxp? If I 
> type "+A I get ä in ttdpatch. Or do you want to make it work like that 
> for the dos version of the patch?

There are several separate issues here.

For the Windows version, the Windows keyboard driver takes care of 
converting key combinations to characters.  However, TTD uses 
byte-oriented Win32 API, so it always gets characters in the active 
Windows code page (which supports only a limited set of characters and, 
depending on what the active code page is, may be slightly or radically 
different from what TTD displays).  Fixing this shouldn't be hard in 
principle -- just use Unicode API instead, and convert to single bytes 
(or UTF-8) as necessary.  What may be messy is text input, since we need 
a way to avoid mixing TTD's native code page with UTF-8.

For the DOS version, the problem is completely different, since DOS TTD 
handles keyboard itself at a very low level.  I think the only 
reasonable solution is to rewrite the existing TTDPatch's keyboard 
handler extension (probably replacing the original handler entirely), 
add Unicode support to ttdpatch.kbd and store the last pressed key's 
Unicode character separately from the one-byte character (the former 
would be accessed only by the text input field; also, I guess we could 
use some otherwise-unused code in the range 0x01..0x1F to signal an 
unmappable Unicode character to the byte-oriented code).  The need to 
avoid mixing UTF-8 with pre-existing native strings is the same here.

The 'combine' solution could be a later addition to this model, but 
AFAIK the key-combo input method tends to be more common, so it should 
be supported first.  (It's also easier to support IMHO, as it's stateless.)
-- 
Marcin Grzegorczyk