FUmminger/haraldalbrecht/ldolse - have to come in on the side of the palette here as well, advanced Chinese students may not need to consult the dictionary more than once or twice per page but less advanced ones are going to be doing so pretty much every line and the popup adds an unnecessary delay. We're not trying to create the document reader you use for everything, we're trying to create the one you use for reading documents in Chinese, and having definitions in a palette fits with that goal.
But we do plan to allow you to hide the palette if you really don't like having it up there all the time, and we're still debating whether to bring up a pop-up definition or just temporarily reopen the palette when you look up a word in that mode.
FUmminger, good point about adding some extra smarts to the popup window though that may prove to be something we have to punt to a later version since it would be rather tricky.
haraldalbrecht - that's the idea behind those left/right buttons on each side, they're supposed to make it easy to look up a smaller subset of a word. So you can either use them to modify the highlight or just tap or tap-drag on the characters in the magnified box to select a smaller portion of the text. But yes, I suppose it might be worthwhile to add an option for it to only look up the first character you tapped on. If you highlight two characters it should (unless there's a bug) only look up those two specific characters and not try to modify the highlight, in theory this should happen with one character too but it probably doesn't right now.
ldolse, agree with you completely that the interface needs to be faster to access, I still think the default behavior should be to give you an open screen since it'll confuse the heck out of less-than-computer-savvy people to open up the reader and then have to figure out how to open a document (even if this is typical behavior in, say, Word), but adding for example an option to prompt you to paste in text from the clipboard if the clipboard contains any Chinese-formatted text might help matters, or making the reader remember its state when exiting so that if you exit while viewing a document and return to it later it won't go to the open box but will bring you right back to document viewing mode.
Making it an editable text box is a no-go, at least for now, we do a whole bunch of crazy stuff with the text display field to enable it to show slices of documents without having to have the entire document in memory at the same time and it wouldn't really be possible to enable editing in it as it stands now at least. We can still use the clipboard simply by copying the contents of the clipboard to a memory buffer and telling it that's the document, but making an actual text editor is a whole different issue.
ipsi - yes, can't really get rid of GB/Big5 yet, however nice it would be to live in a world in which they didn't exist. And yes, relying entirely on the byte order mark wouldn't work with copy-paste, though nobody's going to be doing that in UTF-16 on Palm anyway (couldn't, our Unicode clipboard doesn't work outside of Pleco) - probably for this we should always use the just-realized-we-haven't-added-to-preferences-yet External Text Encoding setting which is already something you're going to update based on which encoding CJKOS is set to use or which encoding your local cell carrier sends text messages in.
Split-screen support actually does exist in the reader now, but is designed for reading bilingual documents (so no edit function) and is about to be dropped from 2.0 (along with "PlecoDoc" format support in general, I think) in favor of bringing it back in a later, more document-centric release. (which may also incorporate a text editor)
ldolse again - Palm just blindly stores the text as a string of 8-bit characters without knowing or caring which encoding they're in, hence the need to configure it manually. Fair point about the BOM, but since it can be kind of tricky to add it to a document that doesn't have it, tech-support-wise it might be better to keep it optional. Perhaps we could add a rudimentary auto-detect feature for encodings which would check for a valid BOM, assume the appropriate Unicode format if it's there and if not do a quick check against the GB/Big5/UTF-8 Chinese encoding ranges and try to make a reasonable guess about which one a document was using.
Fleminator/sfrrr - no, no, no, no, no, we're not dropping Unicode support, that would be a terrible idea not to mention pointless since the software uses Unicode internally. Interesting little game of telephone, though...
, but if there was some sort of auto-detect default that would resolve that issue too.