Pleco for Android Beta 6 Bug Report Thread
- Thread starter mikelove
- Start date
not a bug as such Mike but I notice in the addons section there are a number of files that are in the updated page and some of them are large (the audio files for eg)... is there another download via laptop/pc as before so it doesnt take so long/use up the data allowance on the phone? also is the stroke diagram a paid thing now (cannot remember if I paid for it with the windows phone, old age playing havoc again)... uuummm think thats it for now many thanks...
burdenofhope
进士
Not really a bug, but when I quit reviewing flashcards and want to save the progress for the later I immediately get to the "Resume test in progress"/"Cancel test in progress" screen. I'd like to be redirected further back. 
Shadowdh said:
There will be shortly, we just haven't gotten around to putting the page up yet. Stroke order has to be re-purchased on iOS / Android since we licensed the data from a different source than we used on Palm/WM. (but the new source is platform-agnostic, so you shouldn't have to buy it again in the future unless we add some radical new stroke-order-based feature that requires another kind of data)
burdenofhope said:Not really a bug, but when I quit reviewing flashcards and want to save the progress for the later I immediately get to the "Resume test in progress"/"Cancel test in progress" screen. I'd like to be redirected further back.
All the way out of the Flashcards tab, or just to the main screen of it?
burdenofhope
进士
mikelove said:burdenofhope said:Not really a bug, but when I quit reviewing flashcards and want to save the progress for the later I immediately get to the "Resume test in progress"/"Cancel test in progress" screen. I'd like to be redirected further back.
All the way out of the Flashcards tab, or just to the main screen of it?
Good question. Probably to flashcards main screen, but other people might prefer getting all the way to the main dictionary interface. All I know is, I don't want to resume my test immediately after I quit it.
bug/feature not really in beta 6, in fact it should be a glitch in ABC C-E
entry 记挂 has wrong traditional on 挂. due to that ACB shows as a separate entry, when i enter "jigua" to the search box, the others (with correct trad. chars) are grouped in another search result. there are more words in ABC with that same trad. char wrong, like 一丝不挂. similar things happen, when the pinyin is different, like with 及冠, ABC is different from GF. but all 机关 are in one result, as all have the same trad. and pinyin... (i use merged multi-dict search,experimental)
i understand that this is not really a bug, it depends on the dictionaries, and basically the feature is good. but i need more dicts to clearly see which dict is the one with the incorrect (or more doubtful) data, hehe... (btw, i have all up-to-now available dicts)
entry 记挂 has wrong traditional on 挂. due to that ACB shows as a separate entry, when i enter "jigua" to the search box, the others (with correct trad. chars) are grouped in another search result. there are more words in ABC with that same trad. char wrong, like 一丝不挂. similar things happen, when the pinyin is different, like with 及冠, ABC is different from GF. but all 机关 are in one result, as all have the same trad. and pinyin... (i use merged multi-dict search,experimental)
i understand that this is not really a bug, it depends on the dictionaries, and basically the feature is good. but i need more dicts to clearly see which dict is the one with the incorrect (or more doubtful) data, hehe... (btw, i have all up-to-now available dicts)
Shadowdh said:
There will be, but we haven't reformatted them for that yet - been distracted by the fact that it's Christmas
mfcb said:
Good point. Fixing that in dictionaries can be difficult (generally their editors don't want us mucking around with them), and in fact this problem has been part of the reason why Merged Multi isn't a bigger / non-"experimental" feature yet; we need to come up with some sort of alternate criteria by which to merge them when it's a multi-character word and the simplified + pinyin match. If you go into Settings / Dictionary / Search Settings / Result display and set Merge character set to "Simplified," that will get it to ignore traditional and only match simplified when merging, but that will affect single characters too (which is not necessarily the best idea).
JimmyTheSaint said:
Yeah, we've had a few email reports of this too - we've fixed it for Beta 7, and also added some settings to customize which buttons appear in the toolbar, so that if it miscalculates how much space it has for buttons on a particular weird form factor (as the Galaxy Note seems to be) you can override it.
fishcupcakes
Member
Camera orientation problem with Galaxy Player 4.0. The default camera image for OCR is flipped (as in mirrored around the x axis). Due to this the options to rotate the camera orientation don't help (in addition to the default + 180 and default +270 options simply crashing the app). The only option that works is setting the camera to "natural" mode which sets the camera to a 90 degree orientation to the body of the device, but non-mirrored, so natural + landscape orientation is functional.
fishcupcakes said:
Yes, that's unfortunately the only mode that seems to work - the Galaxy Player's camera driver is very very buggy and we can't find a way to get it working with anything but landscape orientation, if we tell it to switch to any other orientation it gives us a mirrored image and refuses to change it.
In beta 6 the OCR behaves exactly as in beta 5 on my Huawei Ideos X5. It works with "always landscape" and "always 180 degrees", but doesn't when using other options. Here's the description: http://www.plecoforums.com/viewtopic.php?f=20&t=2930&start=45#p24132
Also, the OCR doesn't seem to recognize some vulgar characters like 屄 and 肏 although they can be input by drawing.
Still another bug: When installing everything from scratch, I didn't get "Audio Pronunciation (Male)" or "Audio Pronunciation (Female)" when Pleco started downloading add-ons even though it downloaded the extended audio files.
Also, the OCR doesn't seem to recognize some vulgar characters like 屄 and 肏 although they can be input by drawing.
Still another bug: When installing everything from scratch, I didn't get "Audio Pronunciation (Male)" or "Audio Pronunciation (Female)" when Pleco started downloading add-ons even though it downloaded the extended audio files.
eemeli said:
Could you let me know if changing "180 degrees" to "camera natural" also works? That's the combination we're planning to switch to via a popup for new users (little button shows up at the bottom of OCR asking if the display is garbled and offering to switch to "compatibility mode" if so) so it would be nice to know if it fixes things in this particular case too.
eemeli said:
They're part of the extended / less-common block of the Big5 standard, so the handwriting recognizer covers them but OCR (which needs to maintain a smaller character set since there's a higher risk of / greater consequence to false matches) doesn't.
eemeli said:
Ah, very good catch (relates to the fact that we're now treating the extended modules as the only "paid" parts) - we'll fix it for Beta 7, thanks very much for reporting this.
mikelove said:
This did not work unfortunately. The behavior is the same as with "always 0 degrees", i.e. the text seems oriented correctly but it does not manage to recognize any characters.
I also noticed that the app crashes when starting the OCR on any of the combinations default+90/180/270 in landscape, but only default+180/270 in portrait.
eemeli said:
That's a shame - could you try pointing it at characters upside-down? I.e., flip a book so that it's upside-down, point it at the characters, and see if they're then recognized correctly?
eemeli said:
Could you possibly send me the crash log from that? You can get it with the aLogcat utility, available in Android Market or as an APK from http://code.google.com/p/alogcat/downloads/list - get Pleco to crash, then immediately run it, set it to display everything (no filter) and email / attach / PM me the result.
mikelove said:
Turning the character upside down seems to work when the green rectangle is on the opposite side (w.r.t to the middle) of the screen than the character. Here are some videos and the crash logs: https://www.dropbox.com/s/ffl0fvxhhh5cwa3 . The videos were taken with "always landscape" + "camera default". The OCR didn't recognize the upside down 人 when my hand was casting a shadow, but did manage to after removing the hand (at about 25sec in the video).
Wish you a happy new year!
When Camera Orientation is set to Default, everything works fine EXCEPT when the device is completely upside down (both landscape seem fine, and with the camera facing up (portrait), it's no problem).
The issue seems to simply be that the characters recognized and the recognition box do not display over the correct place in the image. I say this because it still recognizes, and actually, I can get it to recognize characters that are above where the selection box is. Natural Orientation just makes the camera act weird in 3 of 4 directions, and I didn't try any others as I assume they all flip the camera in different ways. I've got a Toshiba Thrive, does anyone else have this issue? (I understand the camera issues can sometimes be device dependent.)
It would be nice to be able to do this this, because holding a book in my lap and recognizing characters with the camera facing up makes me move rather far away front he book, where as simply flipping the device (albeit while blocking my light) allows me to conveniently hold the device and view the text.
EDIT: Correction! There is the same issue when the device is upside down in landscape as well - the recognition is shifted right rather than down.
Both screenshots included.
The issue seems to simply be that the characters recognized and the recognition box do not display over the correct place in the image. I say this because it still recognizes, and actually, I can get it to recognize characters that are above where the selection box is. Natural Orientation just makes the camera act weird in 3 of 4 directions, and I didn't try any others as I assume they all flip the camera in different ways. I've got a Toshiba Thrive, does anyone else have this issue? (I understand the camera issues can sometimes be device dependent.)
It would be nice to be able to do this this, because holding a book in my lap and recognizing characters with the camera facing up makes me move rather far away front he book, where as simply flipping the device (albeit while blocking my light) allows me to conveniently hold the device and view the text.
EDIT: Correction! There is the same issue when the device is upside down in landscape as well - the recognition is shifted right rather than down.
Both screenshots included.
Attachments
eemeli said:
Thanks for these.
The crashes look like they're entirely Huawei's fault - we're calling a perfectly normal Android camera-orientation setting command, one for which no "check if this is an allowed orientation" exists, and it's crashing (rather than simply refusing to change the orientation). So my inclination would be to ignore them and discourage our customers from buying Huawei phones until they start shipping them with fewer bugs. We can certainly make the "compatibility mode" setting do "Always 180" on this model, though.
Supaiku said:
That orientation actually wasn't supported at all until very recent versions of Android, so it's been kind of tricky to get things working well with it, but we'll see what we can do.
Supaiku said:
We're seeing this on our test Xoom here too - hardware in the Honeycomb tablets is almost identical so it's reasonable that it would affect all of them. Honestly, fixing live OCR on tablets isn't a big priority since we don't really expect very many people to use them - ergonomics are pretty awkward - but it seems likely that this will also affect some ICS devices so it's worth putting significant effort into it for that reason.