3.1 Beta Bug Report Thread
- Thread starter mikelove
- Start date
[1] not sure if this is an error, in fact it's probably programmed this way -- "bu" fourth tone sandhi's although are displayed in the dictionary as 4-4 but the audio when read follows the sandhi rules: i.e.: 不是 bu4 shi4 -- audio will read as bu2 shi4 -- I'm just not sure if the audio is supposed to match the "strict" dictionary entry or the sandhi rule.
[2] copying:
trying to copy the English from the above abc entry is impossible!
(maybe my fingers are too fat) either ART -or- zhang will get "clicked" when attempting to copy "gouache" but never actually being able to copy the word itself
[3] Cantonese integration:
as you can, barely, see from the screenshot 多士 even has a GZH entry...but...no JP, no audio...
click+hold GZH - browse entry - will show jp and audio but seems to have some problem integrating with other entries..
[4] pinyin:
(saw this mentioned before)
覅 is still fi'a'o4 and not fiao4
[2] copying:
trying to copy the English from the above abc entry is impossible!
(maybe my fingers are too fat) either ART -or- zhang will get "clicked" when attempting to copy "gouache" but never actually being able to copy the word itself
[3] Cantonese integration:
as you can, barely, see from the screenshot 多士 even has a GZH entry...but...no JP, no audio...
click+hold GZH - browse entry - will show jp and audio but seems to have some problem integrating with other entries..
[4] pinyin:
(saw this mentioned before)
覅 is still fi'a'o4 and not fiao4
Last edited:
Thanks for all of these! 1) is indeed by design and 4) is a known issue (at the moment it's a case of something being too hard to fix to justify doing it for the minor benefit it would offer), but 2) and 3) I'm seeing here so we should certainly be able to fix those for the finished 3.1.
Last edited:
well if you guys do get around to adding pinyin "slots" you can add a biang while you're at it as I'm sure that will be coming in a short time too...(it's already been proposed for encoding as UTC-00791)
another thought I've had since 3.0 came out is about the clipboard reader:
the only way to get to it is through document reader -- open document
to be honest it's kind of hard to get that "clipboard reader" would be under "open document"
I realize that probably the menu is trying to be as clutter free as possible but maybe there's a better way to do this
Alexis
状元
Definitely better. Or even just call it "Reader" to make it consistent with all the other menu items that open something but don't have "open" in the menu name.
Shun
状元
In Beta 2, when I activate "Show dict slider" in Settings > Definition Screen, the dict slider doesn't appear at the bottom of the dictionary definitions pane. (on an iPad 3)
After I changed the color scheme, the dict slider did appear. Perhaps in Settings > Colors, one could add a warning if colors are set in such a way that certain elements would be invisible.
After I changed the color scheme, the dict slider did appear. Perhaps in Settings > Colors, one could add a warning if colors are set in such a way that certain elements would be invisible.
Last edited:
should be. I just remember it taking me forever to find pasteboard reader myself the first time I got on 3.0
where open is a N and not a V
----
I've never tried this before but just had a go and saw that pleco actual doesn't support pinyin searches with tone marks...
I don't know if it's even something in demand but just saw it didn't work
radioman
状元
Now that I am jailbroken, I loaded up the 3.1 Beta. Very pleased to have the opportunity.
Here are just some early comments, currently directed at reading of a PDF.
Reader: PDF File w/OCR
Given a professionally OCRed, error-free document, the Reader function w/OCR is certainly the way to go. The issue I have is with a run-of the-mill document scanned PDF, with pictures, bulleted lists, questions and answers, etc., the OCR result is never 100%. Throw columns into it, and it is impossible to advance through the document a truly sequential manner.
Also, because of nature of these types of errors, in the Reader mode, it is difficult to highlight a incorrectly OCRed character and get the right one. That is, while you can highlight a character and try and handwrite it in. However, being able to shape the green box invariably allows the character(s) in question to be more efficiently recognized/OCRed.
With the Still Photo mode, you can shape the box as necessary, in effect, redacting "on the fly" the areas that give rise to the OCR errors. The result is a more accurate OCR experience.
I am just getting into this so might be missing functionality or workarounds.
Here are just some early comments, currently directed at reading of a PDF.
Reader: PDF File w/OCR
- Program crashes when advancing pages across the bottom of the page on a 225+ page OCR (about 7.9 MB).
- No way to advance rapidly through pages (e.g., from page 1 to page 173).
- Does not maintain green box shape when advancing to next page.
Given a professionally OCRed, error-free document, the Reader function w/OCR is certainly the way to go. The issue I have is with a run-of the-mill document scanned PDF, with pictures, bulleted lists, questions and answers, etc., the OCR result is never 100%. Throw columns into it, and it is impossible to advance through the document a truly sequential manner.
Also, because of nature of these types of errors, in the Reader mode, it is difficult to highlight a incorrectly OCRed character and get the right one. That is, while you can highlight a character and try and handwrite it in. However, being able to shape the green box invariably allows the character(s) in question to be more efficiently recognized/OCRed.
With the Still Photo mode, you can shape the box as necessary, in effect, redacting "on the fly" the areas that give rise to the OCR errors. The result is a more accurate OCR experience.
I am just getting into this so might be missing functionality or workarounds.
Is this on your iPad Mini? If so then I'm seeing a few crash logs from the PDF reading in TestFlight (which collects crash logs even from copies not distributed through its system) - could you possibly email me a copy of that file so that we can forward it to the PDF decoder library folks? It looks like an issue with their character map decoder.
As for OCR, to be honest we're not doing much on that until we revamp the whole system - we certainly do plan to improve the UI for it then, most likely by merging the OCR and reader PDF interfaces actually (since it's kind of ridiculous to have two different interfaces for the same type of file).
As for OCR, to be honest we're not doing much on that until we revamp the whole system - we certainly do plan to improve the UI for it then, most likely by merging the OCR and reader PDF interfaces actually (since it's kind of ridiculous to have two different interfaces for the same type of file).
Alexis
状元
Thanks for fixing this Mike! Wonder if 刘月华 knows that one of here students went on to make the most advanced Chinese dictionary app world.
That was actually the year I was writing the first Palm OS version, so she saw me playing with the beta a few times and commented on it once or twice.
That actually should be happening in most cases already - not sure why it isn't in this one.
EDIT: looks like a perfect storm of database issues in this case - you're using both the new Oxford E-C plus NWP, right? NWP shouldn't be hyphenating that word - the system does factor in hyphens since they're often meaningful - and Oxford E-C looks like it has a bug in certain compound headwords that's resulting in an invisible character that mucks up the merging.
EDIT: looks like a perfect storm of database issues in this case - you're using both the new Oxford E-C plus NWP, right? NWP shouldn't be hyphenating that word - the system does factor in hyphens since they're often meaningful - and Oxford E-C looks like it has a bug in certain compound headwords that's resulting in an invisible character that mucks up the merging.
Last edited: