Re: Unicode in WP - not, and the reasons

Andreas von Heydwolff wrote:
> 
>
http://www.wpuniverse.com/vb/showthread.php?s=2ced1a86231c7867e9f20d4ea93e2792&a
mp;threadid=16431 
> 
> 
> Dear all,
> 
> as an occasional lurker using WP9 in VMware now and then I have found 
> what is for me part of the answer why the Linux product was dropped. I 
> haven't seen it mentioned here but please excuse me if I am repeating 
> the obvious.
> 
> The thread at the URL above explains nicely why WP probably will never 
> get unicode support. Therefore there will be no easy compatibility with 
> modern Linux distros, as far as international usage is concerned.
> 
> My current issue is that the mail merge feature has always been so much 
> better than the OO for Linux solution which I find tedious to use. But 
> at least for me needing German and other special characters on a daily 
> basis exporting the kaddressbook entries to csv and importing this file 
> into WP just doesn't work well. The umlauts get garbled or omitted.
> 
> BTW, does WP X3 have a feature to define masks for importing address 
> data from other sources into its address book? Not having to re-define 
> import filters (field names etc.) every time when an updated data set is 
> being imported would be helpful. A script could do the charset 
> conversion in the Linux csv file and importing it might then just be a 
> few clicks away.
> 
> Greetings,
> 
> Andreas
> 
Andreas: thanks for posting this and the informative link.

I taught German for ten years and used WP 6.x DOS extensively in 
preparing my materials.  It was easy for me to insert umlauts and esszet
by using alt + ascii code on the numeric key pad, e.g. umlaut o = alt 
148.  Moving to WP8/Linux slowed things down by having to use the insert 
character menu.
-- 
Leon A. Goldstein

Powered by Libranet 2.8.1 Debian Linux
System G2

http://www.wpuniverse.com/vb/showthread.php?s=2ced1a86231c7867e9f20d4ea93e2792&a
mp;threadid=16431

Dear all,

as an occasional lurker using WP9 in VMware now and then I have found 
what is for me part of the answer why the Linux product was dropped. I 
haven't seen it mentioned here but please excuse me if I am repeating 
the obvious.

The thread at the URL above explains nicely why WP probably will never 
get unicode support. Therefore there will be no easy compatibility with 
modern Linux distros, as far as international usage is concerned.

My current issue is that the mail merge feature has always been so much 
better than the OO for Linux solution which I find tedious to use. But 
at least for me needing German and other special characters on a daily 
basis exporting the kaddressbook entries to csv and importing this file 
into WP just doesn't work well. The umlauts get garbled or omitted.

BTW, does WP X3 have a feature to define masks for importing address 
data from other sources into its address book? Not having to re-define 
import filters (field names etc.) every time when an updated data set is 
being imported would be helpful. A script could do the charset 
conversion in the Linux csv file and importing it might then just be a 
few clicks away.

Greetings,

Andreas

Leon A. Goldstein wrote:
> 
> Andreas von Heydwolff wrote:
>>
>>
http://www.wpuniverse.com/vb/showthread.php?s=2ced1a86231c7867e9f20d4ea93e2792&a
mp;threadid=16431 
>>
>>
>> Dear all,
>>
>> as an occasional lurker using WP9 in VMware now and then I have found 
>> what is for me part of the answer why the Linux product was dropped. I

>> haven't seen it mentioned here but please excuse me if I am repeating 
>> the obvious.
>>
>> The thread at the URL above explains nicely why WP probably will never

>> get unicode support. Therefore there will be no easy compatibility 
>> with modern Linux distros, as far as international usage is concerned.
>>
>> My current issue is that the mail merge feature has always been so 
>> much better than the OO for Linux solution which I find tedious to 
>> use. But at least for me needing German and other special characters 
>> on a daily basis exporting the kaddressbook entries to csv and 
>> importing this file into WP just doesn't work well. The umlauts get 
>> garbled or omitted.
>>
>> BTW, does WP X3 have a feature to define masks for importing address 
>> data from other sources into its address book? Not having to re-define

>> import filters (field names etc.) every time when an updated data set 
>> is being imported would be helpful. A script could do the charset 
>> conversion in the Linux csv file and importing it might then just be a

>> few clicks away.
>>
>> Greetings,
>>
>> Andreas
>>
> Andreas: thanks for posting this and the informative link.
> 
> I taught German for ten years and used WP 6.x DOS extensively in 
> preparing my materials.  It was easy for me to insert umlauts and esszet
> by using alt + ascii code on the numeric key pad, e.g. umlaut o = alt 
> 148.  Moving to WP8/Linux slowed things down by having to use the insert 
> character menu.

It would be nice if it supported a compose key and dead keys.  This 
would actually mean that it used X for the keyboard decoding and 
wouldn't really care how X managed to produce the key codes.

AFA Unicode is concerned.  I found the argument useless.  They presumed 
that it would have to be based on 16 bits.  This is simply wrong. 
Unicode usually means UTF-8 which is NOT 16 bits per character.  I think 
that it would be easy to convert WP to UTF-8 and UT16.  You have a first 
bite indicating WP coding and a code for the "Code Page" to use, then

the second byte is the character code.  If there is room for two more 
Code Page codes, it should work.  The only modification would be that it 
would have to accept a variable number of bytes (instead of one) for the 
character code.  IIRC, this would be necessary for UTF-8 which uses a 
variable number of bytes.  It uses only one byte for the first 128 
characters of ISO 8859-1 and then uses a Huffman code like system to use 
various lengths of byte strings for other codes.  UT16 is similar except 
that it uses 2 byte words (16 bits) and can represent *all* Unicode 
characters.  But in both cases, WP would have to use the character 
decoding algorithm and use as many bytes or words as necessary.

The problem here is that both types of Unicode Transformation Formats 
only work with a stream.  If WP doesn't read text objects as streams, 
then there would be major problems.

They are going to have to do a major rewrite anyway if they are going to 
be able to use one of the XML formats.

-- 
JRT