3.2.x Bug Report / Feedback Thread

mikelove

皇帝
Staff member
It should be doing that already if it's prompting you for characters or pinyin - is it not? Could you send a screenshot?
 

jurgen85

榜眼
Neither characters nor pinyin works when showing only the definition.

Showing characters and prompting for pinyin (and vice versa) works however. So does defintion plus one of those, or audio.
 

Attachments

  • Screenshot_20201218-221253.png
    Screenshot_20201218-221253.png
    200 KB · Views: 253
  • Screenshot_20201218-221354.png
    Screenshot_20201218-221354.png
    212.1 KB · Views: 289
  • Screenshot_20201218-221820.png
    Screenshot_20201218-221820.png
    191.7 KB · Views: 266
  • Screenshot_20201218-222046.png
    Screenshot_20201218-222046.png
    96.6 KB · Views: 251
  • Screenshot_20201218-222314.png
    Screenshot_20201218-222314.png
    156.4 KB · Views: 248

mikelove

皇帝
Staff member
Ah, I see - wasn't thinking through this clearly but yeah, the choices should match if you've specified a certain length for the test. Thanks.
 
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.

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.
 

Shun

状元
Hi @ACardiganAndAFrown, hi @tomasilheu,

I feel @tomasilheu has a point—the search mode "hollow E" as seen in the screenshot searches inside English definitions, a field that was originally intended for English text and only quite rarely includes Chinese pinyin. On my Pleco, I always only get one and the same match with the hollow "E" active, from my user dictionary, whether I search for "zuzhi", "zu4zhi3", or "zu3zhi1". Tones do not seem to matter, they are simply ignored for English search terms.

Let me include all the search modes from the Pleco manual:

IconFunction
C
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.
E
English search; search all English-to-Chinese dictionaries for the current search term; any letters / numbers entered will be interpreted as English.
[E]
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.
[C]
Full-text Chinese search of English-to-Chinese dictionaries (return English words whose definitions contain a particular Chinese word)
[CC]
Full-text Chinese search of Chinese-to-English dictionaries (return Chinese words whose definitions a particular Chinese word)

[EE]
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.


Never are they all available at the same time, of course. Different symbols appear for different kinds of input: Hanzi, pinyin, English/French/... words.

I'm sure this is just a refresher for many.

Cheers,

Shun
 
Last edited:

Shun

状元
This is more to do with fuzzy pinyin if anything.

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.
 
The only reason it automatically switches to full-search query is because there are no headword matches - the dictionaries search functions are normal.
 

Shun

状元
The only reason it automatically switches to full-search query is because there are no headword matches - the dictionaries search functions are normal.

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. :)
 

mikelove

皇帝
Staff member
I don’t know what zu4zhi3 word you’re trying to look up - is it in any dictionary if you search by characters?

The English results you’re seeing are because in the absence of any pinyin matches it’s trying a search on just the letter portion of the search text in English.
 
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?
 

rizen suha

状元
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?
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).
 
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..
 

rizen suha

状元
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..
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 ...
 

mikelove

皇帝
Staff member
The current Kai stroke order diagrams are actually "experimental" - lightly modified versions of the MakeMeAHanzi project data; we're working on our own official Pleco set of Kai stroke order diagrams, but given how long it takes us to do everything we figured that releasing those in our app was better than simply leaving everyone with only the older Song diagrams until we had new ones ready.

But basically anything to do with Kai stroke order is temporary/unofficial at the moment :)
 
I see, thanks. I'd never really considered the implications of "experimental" on the add-on screen. Speaking of stroke order diagrams, I've only recently discovered "fade strokes"... that's a great little feature. I rarely need to check stroke order beyond the occasional "is it this bit first or that one?", so to see the full order instantly without waiting for the character to draw is really useful.

When I'm as behind as I am with my character practise, every split second counts!
 

Su123

Member
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.
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!
 
Top