It should be doing that already if it's prompting you for characters or pinyin - is it not? Could you send a screenshot?
Huh? I typed zu4zhi3 and it's giving me results for zŭzhī (zu3 zhi1) - the problem is with the tones. The reverse search doesn't matter.You need to click on the E in the right top corner, so you can change the dictionary to chinese C. As of now, it is showing results for the English dictionary, therefore the E.
||Chinese search; search all Chinese-to-English /-Chinese / -German / -French / etc dictionaries for the current search term; any letters / numbers entered will be interpreted as pinyin pronunciations.|
||English search; search all English-to-Chinese dictionaries for the current search term; any letters / numbers entered will be interpreted as English.|
||Full-text English search; search the definitions of all Chinese-English dictionaries for the current search term, interpreting it as English, and returns a list of matching Chinese-English dictionary entries.|
||Full-text Chinese search of English-to-Chinese dictionaries (return English words whose definitions contain a particular Chinese word)|
||Full-text Chinese search of Chinese-to-English dictionaries (return Chinese words whose definitions a particular Chinese word)|
||If for whatever reason you’d like to perform an English full-text search in your English-to-Chinese dictionaries, enter a # before your search term as you would for a Chinese full-text search; the icon EE will indicate that that’s what you’re doing. You can also use this for an English full-text search in Englisht-to-Chinese dictionaries if you’ve otherwise disabled those using the instructions above.|
I thought in the same direction at first, but then changed my mind because I would expect fuzzy pinyin to be able to handle incorrect spellings, as well, which it doesn't appear to in this search mode. But I'm sure @mikelove can shed more light on this interesting detail.This is more to do with fuzzy pinyin if anything.
To me, that is proof that fuzzy pinyin matching is disabled on your Pleco. So, not finding the pinyin you entered in a regular pinyin field, it switches to English full-text search and then finds the pinyin there, thinking you entered an English word. That's my version.The only reason it automatically switches to full-search query is because there are no headword matches - the dictionaries search functions are normal.
the stroke order is consistent with the physical appearance of the hanzi in fznewkai, using 天 as a component. but its not the most orthodox appearance, which would have 夭 (iao1) be a (sound) component. actually all other fonts in pleco (including seal script although under a different morphology) use the orthodox interpretation. i have observed this phenomenon in several other characters and im interested myself in knowing, how much "artistic" allowance is... allowed when designing (the drawing, morphology of) a given hanzi (font).Not a big problem, but I've spotted an inconsistency in the stroke order diagram for the character xiao4 (laugh, smile). I would expect the seventh stroke to be right-to-left, as indeed the screen draws when using the default font, but when using FZNewKai, as I typically do, the screen draws it left-to-right. Is this a bug?
yeah thats also my question, in general, how much artistic "liberty" is acceptable, although a definite answer will be hard to give (in general). i guess. incidentally, i just noticed that fznewkai _does_ use 夭, only the variant in the stroke order diagram uses 天. i guess this is because the stroke diagram actually uses _another_ kai font ...I see the stroke order fits the character's appearance, though perhaps my question is better phrased as "is FZNewKai correct to use 天 as a component of 笑 rather than 夭"? I imagine a character whould have the same components irrespective of how it's displayed (font, handwriting etc) but I could be mistaken. Nothing surprises me when it comes to these characters..
Hello, happy new year! I was wondering if this will be able to be addressed in the next update? Just wanted to check that it’s on the radar - thanks so much!OK, didn't realize this was looking through clipboard history - I actually didn't know that was a feature we ever supported
Anyway we'll investigate this for our next bug fix update, but I'm afraid that probably won't be until January as Apple is about to do their annual holiday shutdown and it's never a good idea to release an update just before then (in case there's something seriously wrong with it + you can't fix it until after the shutdown). In the meantime I'm afraid there's no way to revert to the previous version, but if you have our paid document reader add-on you can save your clipboard to a text file ('disk' icon at the top) and that should save its place correctly.