2.1.2 Released - Bug Report / Feedback Thread

[character]

^ Mike, something I'm looking at for my iPhone app is an 'export/import settings' / 'email settings to developer with problem report' ability. That might speed up resolution of problems like this.

 

[mikelove]

^Mike, something I'm looking at for my iPhone app is an 'export/import settings' / 'email settings to developer with problem report' ability. That might speed up resolution of problems like this.

In the works - even ignoring the tech support benefits, people really want a way to back up their painstakingly-configured preferences - but might be a release or two before it's ready.

 

[djwatson]

There isn't any chance you might be entering an extra character after the #, is there? Or that you're entering a double-width one using a Chinese keyboard (instead of just tapping on the "Full" button)?

Um... *extreme embarrassment*... yes a full width Chinese hash was the culprit. I'd cut and paste it over and over instead of hitting the "full" button.

So sorry Mike! As usual, Pleco is functioning perfectly. Many thanks for your help!

Cheers.

 

[mikelove]

Actually full-width character support is something we've been meaning to add - for Pinyin too, people copy-and-paste in bits of that from time to time. Implementing it in searches would be a bit of work but implementing it for simple copy-and-pastes would be considerably easier I think.

 

[tennonn8]

I encountered an interesting problem in the reader, and I haven't found it reported anywhere else, so let me report it here.

When I open a document that contains phrases in Chinese together with phrases in Russian, the Russian letters are, so to speak, "double-spaced," that is, there's a space character between every two adjacent Russian characters. Russian is BTW my native language and I have lots of very useful texts where Chinese sentences are commented in Russian, so this is kind of important for me.

The document is encoded in UTF-8 and looks perfect in the Notepad under Windows. In Pleco, I didn't forget to choose the same encoding in the document properties. My first guess was that the reader renders two-byte characters incorrectly (except for Chinese characters, of course), so I tried to look deeper into this problem by adding more foreign characters into the same document using that experimental "Edit" feature of the reader. I found out that German umlauts and French accents are displayed correctly (without extra spaces.) I also found out that in the "editor"mode all characters are displayed correctly, without extra spaces, including the Russian ones, but as soon as I go back to the "viewer" mode, the extra spaces are there again. I installed more international keyboards and did some more typing. I input some arbitrary Arabic, Greek and Korean characters. All of them were correctly displayed in the editor, but not in the viewer. Arabic characters simply disappeared in the viewer. (It's not like I'm interested in having comments and explanations in Arabic when reading Chinese in the Pleco reader :shock: , but someone might be...) Greek and Korean characters showed the same behavior, with extra spaces between characters.

The problem is present on both the iPad and iPod Touch 4G. I can attach some screen-shots and provide the text I used if this is necessary. It doesn't look like it should be too difficult to fix it, since the Editor already "knows" how to display these characters correctly, right?

 

[mikelove]

When I open a document that contains phrases in Chinese together with phrases in Russian, the Russian letters are, so to speak, "double-spaced," that is, there's a space character between every two adjacent Russian characters. Russian is BTW my native language and I have lots of very useful texts where Chinese sentences are commented in Russian, so this is kind of important for me.

Thanks for the note on this - it looks like we were using the wrong font to render Russian text; already fixed in the latest internal build.

 

[tennonn8]

When I open a document that contains phrases in Chinese together with phrases in Russian, the Russian letters are, so to speak, "double-spaced," that is, there's a space character between every two adjacent Russian characters. Russian is BTW my native language and I have lots of very useful texts where Chinese sentences are commented in Russian, so this is kind of important for me.

Thanks for the note on this - it looks like we were using the wrong font to render Russian text; already fixed in the latest internal build.

Thank you! So I guess this fix will be included in 2.2 in spite of the fact that some features are going to be postponed in favor of the new OCR feature. Well, the OCR feature seems to be really amazing, so it's certainly worth it to postpone some other features, but I guess everybody wants to have the features that they requested to be nevertheless implemented in 2.2 anyway!

 

[mikelove]

Thank you! So I guess this fix will be included in 2.2 in spite of the fact that some features are going to be postponed in favor of the new OCR feature.

Yes - features we postpone, bug fixes we hold up the release for (unless they're unbelievably time-consuming, which this wasn't).

 

[kun4]

I'm wondering what the cause is of some puzzling behavior I'm seeing on iPhone.

I'm trying to display radicals, and use them as headword in flashcards. This does not seem to work.
I can display these radicals in Wenlin on Mac, and in Anki on iPhone. I can copy/paste them from Anki in a pleco flashcard/dictionary definition or headword; but when I leave the editing window the radicals seem to disappear.
To try to isolate the problem, I've created a text file with these two radicals (attached). When I display the textfile in "Reader", the radicals don't show up. What am I doing wrong?

 

[mikelove]

Looks like a bug in our Unicode Extension B handling - we actually support a lot more Extension B characters than the built-in fonts do, but we have to do it through our own system and it's not liking these couple of radicals; anyway, should be fixed in 2.2, thanks.

 

[jiacheng]

I'm getting a crash on the flashcard search dialog every time I try to remove a field. Currently I change unused fields to "And All cards" as a workaround.

 

[mikelove]

I'm getting a crash on the flashcard search dialog every time I try to remove a field. Currently I change unused fields to "And All cards" as a workaround.

Eek, yeah, that's not good - thanks, should be easy to fix for 2.2. There are actually some surprisingly big bugs in 2.1.2 flashcards that have gone seemingly unnoticed - the batch "remap cards to dict" function is rendered almost completely unusable by one bug, for example, which leads me to think that either nobody's using it or that you're all too polite to report problems

 

[jiacheng]

Batch remapping to another dictionary, while definitely very useful, wouldn't be something you would have to do very often. My personal pet theory though is that they're just waiting until you get the OCR module out .

I just thought of another bug that I encountered but forgot to mention is that occasionally when I select ABC, it will start showing English->Chinese entries when the icon is still clearly showing 中. Not sure if i can reproduce it reliably tho.

 

[mikelove]

Batch remapping to another dictionary, while definitely very useful, wouldn't be something you would have to do very often.

True, but in ~3 months since 2.1.2 came out you'd think at least one of the thousands of people using Pleco flashcards on iPhone would have tried to use that feature, found it didn't work, and written us about it. Very odd... maybe it's an iOS 4.1 thing, we didn't actually bother rolling back the fix / reproducing the bug on a previous OS once we'd fixed it on that.

My personal pet theory though is that they're just waiting until you get the OCR module out .

Which is why I'm keeping quiet about when we submit to Apple this time - we don't want people to neglect to report potentially-serious bugs because they're worried doing so will cause us to hold up / pull back 2.2 while we fix them.

I just thought of another bug that I encountered but forgot to mention is that occasionally when I select ABC, it will start showing English->Chinese entries when the icon is still clearly showing 中. Not sure if i can reproduce it reliably tho.

As far as the software is concerned the ABC C-E and E-C dictionaries are totally unrelated - just happen to use the same abbreviation icon - so it's unlikely it would get confused between them. Though I suppose there could also be a bug that's causing the language auto-detector to fire off in the middle of a particular search... anyway, not that serious a bug, but if you encounter it again please let us know the details (exactly what you were doing at the time / what search you'd entered / what action triggered the switch) and we'll see if we can figure it out. Thanks!