3.2.x Bug Report / Feedback Thread

That's interesting, because on iOS, another font, probably Source Han Sans, is substituted for rare characters. That should be an easy feature to add for Android: Selecting a main font and one for those characters the main font does not cover.
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 ;)
 
@Abun & @Shun I believe that is the correct Pleco behavior for variants as I have seen it.
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. ;)
 
@Abun & @Shun I believe that is the correct Pleco behavior for variants as I have seen it.
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 ;)
 

mikelove

皇帝
Staff member
@Abun - thanks.

We actually support the extended font on Android too - download that in "Add-ons" and you can use whatever CJK font you like for non-extended characters. And NewShuSong is a SongTi like HanaMin so they should go together pretty well.
 
We actually support the extended font on Android too - download that in "Add-ons" and you can use whatever CJK font you like for non-extended characters. And NewShuSong is a SongTi like HanaMin so they should go together pretty well.
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.

extended font.png

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.

extra rare.png

The world isn't perfect, so Pleco has its conundrums, as well, right? :)
 

mikelove

皇帝
Staff member
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 :)
 
We actually support the extended font on Android too - download that in "Add-ons" and you can use whatever CJK font you like for non-extended characters.
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).

And NewShuSong is a SongTi like HanaMin so they should go together pretty well.
Right, I got it mixed up with Source Han Sans… Weird seeing as the name should have given it away^^"

also: 天珩字库 seems to be the only font that supports all ext. f characters atm
Thanks, I’ll make sure to look it up!
 
Last edited:
Not at the moment - we're kind of surprised so many people seem to object to them - but we'll probably do something about them in 4.0.
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.
 
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.
 

mikelove

皇帝
Staff member
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 :)
 
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
 

mikelove

皇帝
Staff member
Ruby Zhuyin is coming in 4.0 (already implemented, in fact already released on Android but due to decisions made 5 years ago in how we designed our text display systems it happened to be an order of magnitude more complicated to implement on iOS).