In a dictionary search for 來往 the result substring highlighting is unexpected in a reduplicated phrase. This may be a feature
(with some tweaks), may be indicative of an underlying bug affecting other places, or may be undefined behavior that you're happy with.
Screenshot included, but the gist of it is this:
1. Search dictionary for:
2. Get a result back that has this highlighting:
iOS 13.5, Pleco 3.2.50
(Happy user, am technical so I notice things. Is this your ideal place to file quirks/issues/bugs or somewhere else? I sent you the last one on Twitter, but without thinking I tagged your personal account instead of Pleco, sorry.)
That's actually not algorithmic at all, those ranges are marked in the data file (precisely so we can deal with duplications / split words / etc intelligently), so it seems like there's an error with that in this case - thanks.
when searching a chinese "word", results in dictionary mode are sorted not primarily according to my-chinese-dictionaries-order, but primarily according to pinyin (it would seem) and (it would seem) _secondly_ sorted according to my-chinese-dictionaries-order.
i have toggled both search-engine>"sort chinese by pinyin" and definition-screen>"dont filter pronuciation" as well as other toggles (like search-from-first), still "word" always appears listed with a chinese-dictionaries order different from my-chinese-dictionaries-order specified in manage-dictionaries.
all of this is although "word" searched was chinese only.
by the way, in the reader, it seems that the dictionary-order _is_ according to my-chinese-dictionaries-order however the _pronunciation_ is taken from the entry chosen as first in dictionary mode!
well, a complicated explanation i know, but i would rather not spend too much time writing this more clearly, unless of course i have to;-)
Yes, that's the intended behavior - since dictionaries can sometimes be missing random useful words, we feel like it's better to aggregate all of them rather than showing you them one after another. However, if you turn off 'skip on button tap' in a dictionary's Manage Dictionaries screen, or simply long press the dictionary icon and switch to the dictionary you'd like, you can search for entries in just one dictionary without seeing them from any others.
trouble is, i want to see all dictionaries. but i want to see and hear my prime-choice-dictionary FIRST (and as default when spoken in reader) when available and not have it overruled by a pinyin sorting. actually the crucial reason for my prime choice dictionary - cross straits - is to access the taiwanese pronunciations... but sometimes cross straits doesnt have "word" and the listing (should) continue with moe, gr, hdc, ...
We're actually addressing that in 4.0 by breaking out "Taiwan Mandarin" as an independent searchable field, but there's not really a good way to solve that in the current app because it doesn't recognize the pinyin in Cross-Straits as being different from any other Pinyin.
that sounds terrific. oh... by the way, when i say pinyin and pronunciation im actually talking about tones!... so eg. ma1 is sorted before ma2. i feel that in any case there should exist an option to list everything according to user specified dictionary order primarily, not being overruled by pinyin/tones sorting. eg. gr and scm also often offer "contrary" pronunciations/tones, so i also would not like having any other dictionary leapfrog them because of pronunciation/tones sorting.
That would be a little more complicated, but search results sort orders are arbitrarily customizable so it should be possible to put GR/SCM results ahead of those from other dictionaries; you'd just run the risk of missing useful results that way.
after updating iOS to the final version 14.0 and Pleco to version 3.2.51 on my iPhone XR, the scroll bar is about 30% higher than the actual screen height in the Organize Flashcards screen, which means that it isn't possible to reach the bottom of a flashcard listing by dragging the scroll bar handle. Completely closing and restarting Pleco leads to the same result. In other places like the Dictionary screen, the scroll bar works correctly. Please see the following screenshots:
Since scroll bars have been draggable by default on iOS since version 13 or so (with haptic feedback) and Pleco introduced this feature much earlier, would it perhaps be technically easy to add the same haptic feedback to Pleco's scroll bars, as well?
Thanks - it's not hard to switch to the standard iOS draggable scrollbars in cases like this, but since it is kind of a pain to support both systems simultaneously, we've generally been holding off on it until we get to the point of requiring iOS 13 as a minimum. But we'll see whether it's easier to support both systems in Organize or fix this bug directly.
Thanks - we switched PDF decoder libraries (for compatibility + licensing reasons - made our app a lot smaller / faster-loading to rely on the built-in iOS PDF decoder instead of a third-party one) and have been steadily adding back missing features from the old one as we update it, so we'll make sure that's in the queue.
I recently updated to Pleco 3.2.53, and am currently at iOS 12.4.8 on my iPad Air (original) and 13.5.1 on my iPhone SE. I'm having a problem with PDF viewing on my iPad; it works just fine on my iPhone.
Specifically, on my iPad, I'm reading a PDF, and regardless of the setting of Settings->Reader->Vertically scroll PDFs, I cannot scroll the PDF horizontally, and the navigation thumbnails at the bottom do nothing. (Both horizontal scroll and the navigation thumbnails work just fine on my iPhone.) One potential complicating factor is that I have a dead spot on my iPad touchscreen, about 1 cm square, at the lower-left corner (in portrait mode). However, the rest of the bottom edge is just fine; for example, I can type the "undo," "keyboard," "radical," etc. buttons just fine. Any thoughts about what might be causing this? Should I uninstall and reinstall?
One more small "bug": It's not really important, but it's bugged me for a while, and maybe you can explain why the UI works the way it does on the iPhone. In the dictionary, there are buttons for handwriting and keyboard, to switch between handwriting input and keyboard input. Likewise, there are buttons for 中 and 英, to switch between Chinese and English headwords.
What's always bugged me is that the input buttons show what the mode will switch to, whereas the language buttons show with the mode is now. That is to say, if I'm in keyboard mode, the input button has the brush icon, to switch to handwriting. On the other hand, if I'm currently in Chinese mode, the language button is labelled 中, showing what the mode is now. This difference doesn't show up on the iPad, where both buttons show what the mode will switch to.
Is there some reason why that should be, or is that unintended behavior?
ETA: Still one of my all-time favorite apps, over a decade on now—a very satisfied customer since my Palm handheld!
Sorry, for some reason I didn't notice this one before now.
Vertically scroll PDFs was broken in 3.2.53 but should be fixed in 3.2.54 - update via the App Store "Updates" tab.
中 / 英; you're right that there is a mismatch there. Basically it's worked that way for a long time - before our iOS app, even - and we were reluctant to reverse the meaning of that button even when we moved it from the top toolbar to the keyboard. But we're doing away with it in 4.0 anyway, I'd rather not change in in the meantime because again it would mean suddenly changing it from what people are used to.