Pleco for Android Beta 7 Bug Report Thread

[stephanhodges]

Saving clipboard text as a file doesn't show up in the "recent files" section. Thus, I also could not bookmark anything. Work around was to first save, then immediately reopen.

When using the "Open file", it didn't open in the saved file location, but rather at the root of the file system. I'm on an ASUS Transformer tablet. I would have expected it to open in the last place (where I saved it). Perhaps that's a setting? For tablets, I think it makes sense this way, since it's very easy to navigate back to the root, since the screen is so large. I could see small phone users wanting the opposite default behavior. :lol:

When tapping a bookmark to return to that place in the text, I was surprised to find that it didn't restore the text highlight that I had when creating the bookmark. I'm used to that behavior in ebook readers (such as Kindle). That makes it hard to actually identify WHERE the bookmark is, at least on a tablet. It didn't restore it to the exact middle (portrait mode) of the screen either.

Will there be any future enhancements to actually show bookmarked text (such as a colored underline, etc)?

 

[mikelove]

Saving clipboard text as a file doesn't show up in the "recent files" section. Thus, I also could not bookmark anything. Work around was to first save, then immediately reopen.

Good catch, thanks.

When using the "Open file", it didn't open in the saved file location, but rather at the root of the file system. I'm on an ASUS Transformer tablet. I would have expected it to open in the last place (where I saved it). Perhaps that's a setting? For tablets, I think it makes sense this way, since it's very easy to navigate back to the root, since the screen is so large. I could see small phone users wanting the opposite default behavior. :lol:

It actually should be doing that already, but Save and Open track their last-used directories separately - is one of them reopening in the root directory even when you previously navigated to a specific one?

When tapping a bookmark to return to that place in the text, I was surprised to find that it didn't restore the text highlight that I had when creating the bookmark. I'm used to that behavior in ebook readers (such as Kindle). That makes it hard to actually identify WHERE the bookmark is, at least on a tablet. It didn't restore it to the exact middle (portrait mode) of the screen either.

We actually key the bookmark to the top of the page, not the text you've highlighted. The small shifts are tough to avoid since often a line will be halfway off / halfway on the page.

Will there be any future enhancements to actually show bookmarked text (such as a colored underline, etc)?

Yes, bookmark markers and notes are both coming, as are a number of other interesting things (the ability to make document-specific glossaries, e.g.).

 

[stephanhodges]

We actually key the bookmark to the top of the page, not the text you've highlighted. The small shifts are tough to avoid since often a line will be halfway off / halfway on the page.

Hmm. It actually ended up about 3 inches down the page. That's for a tablet, so I felt that was a fairly good place to put it, once I found it That gives some context to where I was before.

Once the bookmarks are visible in text, it will be a great feature.

 

[stephanhodges]

When in the reader, it doesn't recognize USR dictionary entries if they have pinyin for the headword. It does work if the headword is characters. By itself, that's probably not a bug, but, if not a bug, then perhaps it shouldn't be possible to create USR dictionary entries (Chinese) with only pinyin?

I made the card I'm mentioning before I had installed Google's pinyin keyboard, so there wasn't any way to type/enter anything but pinyin, and there's no option to use Pleco's input system(s) when creating dictionary entries. (That's my desired solution).

I realize I've "sort of" mentioned this before, although not with the aspect of the reader still not recognizing the dictionary entry.

 

[mikelove]

Hmm. It actually ended up about 3 inches down the page. That's for a tablet, so I felt that was a fairly good place to put it, once I found it That gives some context to where I was before.

That's actually rather odd - were you using your tablet in a different screen orientation the second time, by any chance?

When in the reader, it doesn't recognize USR dictionary entries if they have pinyin for the headword. It does work if the headword is characters. By itself, that's probably not a bug, but, if not a bug, then perhaps it shouldn't be possible to create USR dictionary entries (Chinese) with only pinyin?

That's normal - the reader matches characters and so it requires characters, matching only on Pinyin would require us to be able to reliably automatically convert characters to Pinyin (a rather iffy prospect) and even if we did there'd be the risk of a lot of false matches.

I made the card I'm mentioning before I had installed Google's pinyin keyboard, so there wasn't any way to type/enter anything but pinyin, and there's no option to use Pleco's input system(s) when creating dictionary entries. (That's my desired solution).

We might introduce that eventually, but given the widespread availability of other free Chinese IMEs on Android I'm not inclined to make it a priority over other features that only we can add.

 

[TheAlmightyBob]

So, I see that there is a Beta8, but I haven't had time to test it . Thought I should mention this in case it wasn't already dealt with. ..

When using the ocr demo with 课程，it properly identifies those two characters in the overlay, but displays the "definition " for 课表。 there is a dictionary entry for 课程表, but that is not what it is showing .

Very strange.

 

[mfcb]

When using the ocr demo with 课程，it properly identifies those two characters in the overlay, but displays the "definition " for 课表。 there is a dictionary entry for 课程表, but that is not what it is showing .

Very strange.

i experienced something similar, right now i am still unsure if it is a feature or a bug, this seems to be related:

when searching a word (forgot which one it was in my case) and that word is not in any dict, but happens to be in an example sentence, then that entry gets shown, but not necessarily from the dict with the relevant example sentence...
seems that this "feature" takes priority over incomplete entries (like 课程表), is there an option to disable it?

 

[mikelove]

When using the ocr demo with 课程，it properly identifies those two characters in the overlay, but displays the "definition " for 课表。 there is a dictionary entry for 课程表, but that is not what it is showing .

That's because they're an alternate version of that headword (listed as such in the definition) - we'll try to tweak it so that the demo shows that "also written as" text as well in the finished version, thanks.

when searching a word (forgot which one it was in my case) and that word is not in any dict, but happens to be in an example sentence, then that entry gets shown, but not necessarily from the dict with the relevant example sentence...
seems that this "feature" takes priority over incomplete entries (like 课程表), is there an option to disable it?

Did you turn on the "Integrate into Chinese" option in Settings / Dictionary / Search settings / Full-text? If so, turn it off and that should disable this - we leave it off by default because it has this unfortunate side-effect.