🚀 go-pugleaf

Josef Drexler wrote:
> The only new feature in alpha 73 is complete Unicode support

Well, not really complete: limited to Plane 0, no bidi support, no 
combining character support ;-)

But seriously, what TTDPatch really lacks now is a Unicode support in 
the keyboard handler.  Hmm, that's going to be rather difficult -- the 
existing code assumes 1 byte per character throughout (and DOS version 
assumes 1 character per key).

-- 
Marcin Grzegorczyk

On Wed, 15 Feb 2006 15:19:38 +0100, Marcin Grzegorczyk wrote:

> Josef Drexler wrote:
>> The only new feature in alpha 73 is complete Unicode support
> 
> Well, not really complete: limited to Plane 0, no bidi support, no 
> combining character support ;-)

Well, yes, it's UCS Level 1.

> But seriously, what TTDPatch really lacks now is a Unicode support in 
> the keyboard handler.  Hmm, that's going to be rather difficult -- the 
> existing code assumes 1 byte per character throughout (and DOS version 
> assumes 1 character per key).

It think it may be easier to implement that at the text input level. 
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.

-- 
   Josef Drexler                 |       http://jdrexler.com/home/
---------------------------------+---------------------------------------
 Please help Conserve Gravity    |  Email address is *valid*.
 Boycott multistory buildings.   |  Don't remove the "nospam" part.

Josef Drexler wrote:
> On Wed, 15 Feb 2006 15:19:38 +0100, Marcin Grzegorczyk wrote:
> 
  > It think it may be easier to implement that at the text input level.
> 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?

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

Daan wrote:
> Josef Drexler wrote:
> 
>> On Wed, 15 Feb 2006 15:19:38 +0100, Marcin Grzegorczyk wrote:
>>
>  > It think it may be easier to implement that at the text input level.
> 
>> 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?

That's because you're using the dutch keyboard setting which has " as a dead 
key.  The "compose" key is more general though, for example <compose , c> 
gives me ç, <compose = C> gives me €, <compose 1 2> is ½, and <compose a e> 
is æ, and thousands more variations like that.

-- 
    Josef Drexler                 |       http://jdrexler.com/home/
---------------------------------+----------------------------------------
  Please help Conserve Gravity    |  Email address is *valid*.
  Play Chess, not Basketball.     |  Don't remove the "nospam" part.