ABY, CCY and GZH word - no Cantonese pronunciation tho.
3.2.x Bug Report / Feedback Thread
- Thread starter mikelove
- Start date
ABY, CCY and GZH word - no Cantonese pronunciation tho.
Source Han Sans, according to its readme (https://github.com/adobe-fonts/source-han-sans), only covers “complete URO, Extension A, and contemporary hangul syllable coverage, [as well as] the following 256-character Unicode blocks: U+00xx [ASCII], U+11xx [Hangeul], U+2Fxx through U+33xx (except for U+332C) [Hangeul and Kana], U+D7xx [Hangeul], U+FFxx [also ASCII??], and U+1F2xx [special characters for Japanese icons].” Extensions B through F (which are in the range U+200xx through U+2Fxx) are missing. There are a few extension fonts (i.e. seperate font files for the extension characters) for SimSun and PMingLiu at least, but at least the ones I have only cover up to C or D. To my knowledge HanaMinB is the only font which covers E. F is rather recent – only introduced in June – so it’s not covered yet, at least not in the version I have from the Ubuntu repositories. So far I have yet to encounter characters which need F though (but I do frequently use some from E so I do need that).
I could of course use HanaMin only as a fallback font and FZNewShuSong for the rest, but with the former being Songti and the latter Heiti, they don’t mix very well.
In any case, maybe we should move this discussion to a different thread if you’re interested in pursuing it further
Shun
状元
I agree that Pleco's behavior is proper, there just seems to be an issue with the underlying data. I agree with Abun because the way it's displayed in the Dictionary, you'd have two 聽s and no 者. Of course, a Google search returns no matches for a variant where the 者 (after the slash) could be replaced by 聽 (before the slash).
In any case, maybe we should move this discussion to a different thread if you’re interested in pursuing it further
Nice font research! No worries, I had just guessed it was Source Han Sans because of the way it looked.
Yes, variant deletion for the flashcard works as it should. The problem is the variants are indicated incorrectly. As it is, the entry appears as 言者無心听/聽聽/者有意 (i.e. 聽 is treated as a variant for 听 and 者 is treated as a variant for the second 聽). As a result, the traditional field when exported to a flashcard shows – with variants deleted: 言者無心听聽有意. And I think we can all agree that that is not an acceptable variant spelling for 言者無心，聽者有意, much less the standard one
Shun
状元
Just to explain my incorrect "Source Han Sans" guess. A small number of characters have a sans-serif font, maybe 1% of all characters. (for an example, see the lower half of screenshot) The remainder are serif fonts.
The rarest characters at the end of the list are smaller & look like the character components in CHARS. Presumably, those aren't part of HanaMin.
The world isn't perfect, so Pleco has its conundrums, as well, right?
That's because we fall back on the system PingFangSC/TC fonts (which look very very similar to Source Han Sans) first, before falling back on HanaMin. I suppose if you've selected FZNewShuSong as your default font it would make more sense for us to favor HanaMin over them but this is one of those things that comes up so infrequently that we don't spend a lot of time thinking about it
Yep, that’s what I’m using on Pleco. I referred to the Ubuntu repository version because I checked the support on my desktop (I have no idea what characters were added in Ext. F so I just looked up the wiki page with my browser font set to HanaMinB).
Right, I got it mixed up with Source Han Sans… Weird seeing as the name should have given it away^^"
Thanks, I’ll make sure to look it up!
Last edited:
rizen suha
状元
is there an option to disable // markers in definitions?
rizen suha
状元
thanks. i personally dont need to see them. and not needing them, they are kind of in the way, "clutter up" the reading of the info that i _am_ interested in. thanks for your reply and intention to have a look at it in 4.
rizen suha
状元
having invested perhaps 500 dollars on pleco, this question popped up: how does "pleco inc" (legally) guarantee the continuity of ("contracted") services (until a very far point in the future) over and beyond individual persona (eg you, the owner), in any event (eg selling pleco inc to company x)...? thanks.
Well, our license agreements with publishers are structured in such a way as to ensure that your rights to use a dictionary are independent of (and outlive) our rights to keep selling it. So a reduction in our dictionary portfolio would not affect your purchases.
As far as our more basic survival, though, aside from the fact that we've been in business for longer than Facebook, we aren't really able to *legally* guarantee anything because we can't ensure that our app will keep working forever absent someone maintaining it; whatever succession plans we might have, nobody's going to promise to keep updating our app forever if that turns out to no longer make financial sense.
As a practical matter, the cost of keeping our app working on new iOS / Android updates is small enough relative to our revenue that it's extremely unlikely someone would not be willing to take that on; if I die or become a monk tomorrow there would be all sorts of people interested in taking over Pleco. Aside from the cost of developing software updates updates, our server hosting costs are minimal, and maybe 80% of that small sum is bandwidth for people downloading our free Android app outside of Google Play (something that we could easily limit to paying customers if we needed to).
But if, say, we encounter a situation like 2008 where Palm and Windows Mobile both abruptly died and we had to rewrite our app mostly from scratch for two brand new platforms, it's quite possible a post-mikelove Pleco would not survive that; then again, neither would most of the other apps you've purchased (certainly few Palm/WM apps are still going now), or probably even much of the other digital content.
Assuming I do not in fact die or become a monk, though, my youngest kid is 16 years away from college so I have a pretty strong incentive to keep this very flexible business I can do from home working until then
As far as our more basic survival, though, aside from the fact that we've been in business for longer than Facebook, we aren't really able to *legally* guarantee anything because we can't ensure that our app will keep working forever absent someone maintaining it; whatever succession plans we might have, nobody's going to promise to keep updating our app forever if that turns out to no longer make financial sense.
As a practical matter, the cost of keeping our app working on new iOS / Android updates is small enough relative to our revenue that it's extremely unlikely someone would not be willing to take that on; if I die or become a monk tomorrow there would be all sorts of people interested in taking over Pleco. Aside from the cost of developing software updates updates, our server hosting costs are minimal, and maybe 80% of that small sum is bandwidth for people downloading our free Android app outside of Google Play (something that we could easily limit to paying customers if we needed to).
But if, say, we encounter a situation like 2008 where Palm and Windows Mobile both abruptly died and we had to rewrite our app mostly from scratch for two brand new platforms, it's quite possible a post-mikelove Pleco would not survive that; then again, neither would most of the other apps you've purchased (certainly few Palm/WM apps are still going now), or probably even much of the other digital content.
Assuming I do not in fact die or become a monk, though, my youngest kid is 16 years away from college so I have a pretty strong incentive to keep this very flexible business I can do from home working until then
rizen suha
状元
very good and satisfying answer. thanks... so I have a pretty strong incentive to keep this very flexible business I can do from home working until then
rizen suha
状元
feature request: enhanced support of zhuyin. currently the zhuyin transcription is quite "wide" fontwise and occupies a lot of space, causing it (with longer texts) to become (visually) out of sync with the text that it is transcribing. also: would it be possible to implement vertically scripted zhuyin (one character phonetizised by at most 3 z-symbols)? ideally, the vertical transcription should be offered "stand alone" (as presently) and "on character" (on the right side of each character). actually, the "on character" mode (offered in taiwanese printed media) is the one mayor reason why i prefer zhuyin over pinyin. thanks