Change external text encoding quickly

gandq

探花
Hi Mike.

I wonder if it would be possible to somehow make a quicker switch of the external text encoding possible? Or even an automatic detection of the encoding?

I read both, GB and Big5 encoded texts on my palm and look up unknown words with the PD resident. Having to switch the encoding setting from within PD each time is quite cumbersome. Maybe you could add a button for switching the encoding setting to the resident?

I know, my request might be a bit specific and most people probably only use either GB or Big5 but not both charsets, but i thought i still might ask and hear what you think.


Greetings,




jo.
 

mikelove

皇帝
Staff member
That might be possible, but you're more likely to see something like this in the document reader we're planning for 2.0 - that should allow you to easily select the text encoding whenever you open a file. With the document reader interface, I'm worried that a function like that could end up confusing users - someone accidentally taps the encoding switch button, the screen turns to gibberish and they have no idea why that happened or how they can undo it.

Of course we can always bury the button in a preferences option somewhere (button only appears if the option is enabled), but the current total of 7 preferences screens is already pushing it and if we break into double digits in 2.0 I think people might actually start to laugh at us :D
 
A

Anonymous

Guest
quicker switch of the external text encoding possible?

Hi I was wondering if I can add an opinion here about encoding switches.

In theory if we are just trying to view som GB or Big5 characters using
the latest Palm like PalmTX wiht CJKOS installed there shouldn't be any need to switch from GB or Big5 to view. This is what it says on CJKOS website. CJKOS provides automatic detection of either ecoding. No support yet for Unicode characters which is used in Plecodict

Can future PD be designed in similar fashion for "external text encoding"?
i.e auto detection.. I don't know how its done but such technicalities will be hidden and transparent to the user for ever.

The present version of Palm OS does not support unicode/doublebyte characters but presumably the next version of Palm OS will support it. When this happens switching will probably be even more redundant.
(Because I foresee most programs will be using unicode.)
 

mikelove

皇帝
Staff member
Unfortunately, I'm afraid this would not be possible in PlecoDict. The basic problem with auto-detection schemes like you describe is that they require a significant amount of text to work at all accurately. Many of the Big5 character codes are also GB codes (for different characters), so given a sample of just 2 or 3 characters (which is all we'd generally have with copy-and-pasted text or Instant Access lookups) there's almost no way to reliably determine whether they're in GB or Big5. Some Big5 character codes work only in Big5 and not in GB, but you can easily go through quite a few Big5 characters without encountering one of those. Even CJKOS' system occasionally gets this wrong, in spite of having an entire screen full of text to work with.

It would be a little like trying to determine if a piece of text was in Chinese or Japanese based on 2 characters; with an entire sentence it would be easy, as there are lots of Chinese characters that the Japanese don't use and Japanese has the hiragana/katakana alphabet characters which the Chinese never use, but with just a few characters you could not always be certain whether you had the right language.
 

gato

状元
Of course we can always bury the button in a preferences option somewhere (button only appears if the option is enabled), but the current total of 7 preferences screens is already pushing it and if we break into double digits in 2.0 I think people might actually start to laugh at us
Maybe you can add encoding as a menu item whenever the user is using the reader, like in Firefox and IE.
 

mikelove

皇帝
Staff member
Yes, that's a very elegant way of handling the problem. A tiny bit less convenient for those who change encodings frequently, but much better than having to reopen the full program and change the setting there. Thanks for the suggestion.
 
Top