Feature request (various things)

rizen suha

状元
FD3B12B1-34C2-4388-A1A3-0D1C159E90B0.png
epub reader (repeat requests): please dont cover text when not necessary. here the arrow might as well point to 恐 (and leave the whole word 唯恐 visible) instead of pointing to 唯 (and pop-covering-up 恐). also, when selecting a text (as here) would dearly like to have the whole screen dimmed EXCEPT from selected text and pop-up (instead as currently, dim-lighting selected text). thanks
 

Shun

状元
View attachment 2572
epub reader (repeat requests): please dont cover text when not necessary. here the arrow might as well point to 恐 (and leave the whole word 唯恐 visible) instead of pointing to 唯 (and pop-covering-up 恐). also, when selecting a text (as here) would dearly like to have the whole screen dimmed EXCEPT from selected text and pop-up (instead as currently, dim-lighting selected text). thanks

I just had that idea regarding your second feature request: For a static display (without scrolling, which is impossible when a bubble is shown), couldn't one just convert the entire screen area to a bitmap (like a partial, internal screenshot), then apply the dimming to that bitmap and display that? When the user taps outside the bubble, the bitmap is discarded and the normal display resumes. I feel that would be relatively trouble-free as opposed to having to change the HTML. Just a thought, maybe I'm all wrong. :)
 

rizen suha

状元
thxs shun for your interest. it is already possible to overlay the html with a pesky dimmer;-) apply that everywhere minus selection. furthermore and optionally, menu bars can be tinted to match so as to give a lights down feel. thanks
 

Shun

状元
I guess it would have to be an option, because I usually like to see the context of what I tapped and not have it dimmed. And anyhow, Mike said it was a tricky task to do cleanly. Perhaps even my idea above would be hard to implement in a robust way. I think Mike has definitely made a note of your idea on dimming the background.

A long time ago, I also asked about bubble placement and size. Mike then said it was quite hard for the algorithm to find out where on the screen the word that was tapped on was. It made sense to me. That may be why your first feature request may also be trickier to implement than it seems, because the algorithm can't easily know when a word is separated/wrapped.
 
Last edited:

mikelove

皇帝
Staff member
epub reader (repeat requests): please dont cover text when not necessary. here the arrow might as well point to 恐 (and leave the whole word 唯恐 visible) instead of pointing to 唯 (and pop-covering-up 恐).

Not sure about the exact pixel dimensions here but it looks like doing that might leave too little space for the popup bubble. Or it might be close enough that it's erring on the side of keeping the bubble up high rather than having it be clipped. Can investigate anyway.

For a static display (without scrolling, which is impossible when a bubble is shown), couldn't one just convert the entire screen area to a bitmap (like a partial, internal screenshot), then apply the dimming to that bitmap and display that?

The tricky thing there is that the page can nonetheless update after we make the bitmap without our necessarily being aware of it. Or even the act of bitmap-making itself can cause an update. Or the bitmap can be a slightly different size from the page, or positioned a bit differently (e.g. assorted wackiness with iPhone X edge margins / notch, etc. And Apple have introduced a major breaking change in web view scrolling in I believe every major iOS update since we launched Web Reader, so it's something we'd not only have to untangle the first time but likely spend a lot of time untangling yet again on every system update.

Honestly I think the best solution to all of this is to do less looking-up of stuff on web pages and use Reading Mode more; all of our paid e-books (a collection that will soon be expanding greatly) work in Reading Mode exclusively, and EPUB will shortly have that option too (and it's already how we do EPUBs on Android). We have no intention of getting rid of the option for direct tap-lookups on web pages anytime soon, but in the longform reading use cases where minor aesthetic nits like this would likely be the most bothersome I think we're much better off investing our time in expanding Reading Mode support rather than trying to hack UIWebView into presenting stuff in a more aesthetically pleasing way.
 

rizen suha

状元
Not sure about the exact pixel dimensions here but it looks like doing that might leave too little space for the popup bubble. Or it might be close enough that it's erring on the side of keeping the bubble up high rather than having it be clipped. Can investigate anyway.
like so:
3369BC1E-332C-432D-A711-C86BEE836BB2.png
(with a bonus feature: mark selection by inverting!)

AND (also a repeat request) please make that bubble larger. thanks for listening and the feedback. im using the reader every single day so this is no small matter to me.
 
Last edited:

rizen suha

状元
The tricky thing there is that the page can nonetheless update after we make the bitmap without our necessarily being aware of it. Or even the act of bitmap-making itself can cause an update. Or the bitmap can be a slightly different size from the page, or positioned a bit differently (e.g. assorted wackiness with iPhone X edge margins / notch, etc. And Apple have introduced a major breaking change in web view scrolling in I believe every major iOS update since we launched Web Reader, so it's something we'd not only have to untangle the first time but likely spend a lot of time untangling yet again on every system update.

Honestly I think the best solution to all of this is to do less looking-up of stuff on web pages and use Reading Mode more; all of our paid e-books (a collection that will soon be expanding greatly) work in Reading Mode exclusively, and EPUB will shortly have that option too (and it's already how we do EPUBs on Android). We have no intention of getting rid of the option for direct tap-lookups on web pages anytime soon, but in the longform reading use cases where minor aesthetic nits like this would likely be the most bothersome I think we're much better off investing our time in expanding Reading Mode support rather than trying to hack UIWebView into presenting stuff in a more aesthetically pleasing way.
this is bit beyond me. you are already capable of overlay html dimming the text area. and you can tint menu bars as per already implemented config functionality....
thanks
 

mikelove

皇帝
Staff member
The screenshot in your previous post shows what we're talking about - it's in our own reading view rather than a web view, so we can do whatever we like with dimming / highlighting / correct area selection. So my preference is to eliminate whatever barriers there are to using our view for everything, rather than spend a bunch of time trying to get things working better in web views (in what would inevitably be a very hacky / non-durable way).
 

rizen suha

状元
The screenshot in your previous post shows what we're talking about - it's in our own reading view rather than a web view, so we can do whatever we like with dimming / highlighting / correct area selection. So my preference is to eliminate whatever barriers there are to using our view for everything, rather than spend a bunch of time trying to get things working better in web views (in what would inevitably be a very hacky / non-durable way).
sounds just dandy! thanks
 

rizen suha

状元
flashcards feature request. multiple simultaneous "test modes" modality. i go through N cards learning meaning (testmode=meaning) while also trying to memorize hanzi form (~writing) and pronunciation (incl tone). thereby i learn the meaning perfectly, no problem. but soon thereafter i realize that my hanzi writing recollection is miserable. so i repeat the N cards with testmode=writing. samo for pronunciation. coming full circle, to my dismay, i find that i have now forgotten much of the meanings. and so on i continue in a loop until all is in order. i believe it would be much more efficient and cognitive sound, if i could study cards with testmode=simultaneous randomized meaning/writing/pronunciation. thus binding everything firmly together in a much more natural (and fun) way. can do?
 

lilly54

Member
I don't think there is a feature for this, but a feature that shows pinyin ruby text or simply the characters with the tone colours on the reader would be very helpful.
Also is 4.0 going to come out soon? (as in this year, or early next year)
Thank you so much for this wonderful app, it helps me every day.
 

mikelove

皇帝
Staff member
That’s done for it too. We’re not making any public estimates on 4.0, we’ll release it when it’s ready but not before; there’ll be quite a lot of warning, though, it’ll likely first appear as a public iOS beta.
 

plecorich

Member
I mentioned this in this thread: https://www.plecoforums.com/threads/antonyms-synonyms-not-displayed-no-more.5783/ , but a Synonym and Antonym feature would be great for those who can already read a significant number of individual characters and were using the Synonym and Antonym feature to learn adjacent vocabulary.

It was one of the MOST useful features in the Pleco app for me when the feature was still available. Absolutely fantastic way to quickly learn related terms that would add variety and nuance to my writing and conversation (not to mention greatly increase comprehension of TV news and documentary using more "high register" (ie. more sophisticated) terms).

Thank you
 

mikelove

皇帝
Staff member
Thanks, we'd like to add that again but it's just a problem of finding or developing the right data.
 

plecorich

Member
Thanks for letting me know Mike - hopefully you can guys will be able to come across the right data to implement something similar.


@wibr - I looked in the Add-Ons section of my Pleco app, but I don't see a Taiwan Ministry of Education dictionary (either in the paid or free dictionaries section). Is this a separate add-on I need to manually install myself?

Thanks!
 
Top