Nicolas Mailhot wrote:
Le Jeu 26 juillet 2012 09:32, Akira TAGOH a écrit :
Well, I see what Nicolas wants to do here. since Japanese characters
on Unicode's CJK Unified Ideographs is a subset of Chinese characters,
I think he wanted to avoid picking Droid Sans Japanese up for Chinese
anyway.
But it wouldn't be picked, even without 'lang' rules, at least it isn't
on my machine. Even if I use target="scan" to assign a single family
name to all Droid fonts, the 'lang' of DroidSansJapanese.ttf will still
only be 'ja', and won't be taken into account when enumerating or
matching fonts for a different locale:
sun2:~)fc-list ':lang=ja' file family | grep DroidSansJapanese
/export/pub/fonts/Droid/DroidSansJapanese.ttf: Droid Serif,Droid Sans
sun2:~)fc-list ':lang=zh' file family | grep DroidSansJapanese
Ideally, I'd like the target="scan" lang-specific rules to generate a form
of simulated locl table. I know the current rules I use don't do that, but
I guess they are a sort of RFE on my part :)
I think Droid is a good showcase of the dead-end
selecting-lang-by-font-name is : if we don't hide the various
lang-specific droid names to the user, it only takes two or three
droid-like families to make font selection totally unusable in most apps.
That's what I wonder. Imagine someone created a document in a word
processor on Android, or maybe on Windows. Would they be able to
directly choose 'Droid Sans Japanese' etc. out of their selector? If
not, then you're right and it makes sense to hide the name. If yes, then
fontconfig should enumerate the original full name, and maybe provide
the usual 2-way fallback from/to 'Droid Sans'.
Raimund
--
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
