Around 15 o'clock on Feb 27, Daichi Kawahata wrote: > Is there any possibility the following (Kanji reading: Kyo-ka-sho, > meaning: textbook, font for textbook) > > NtMotoyaKyotai,NT???g????????2,NT??????2:familylang=en,ja,ja > NtMotoyaKyotai,NT???g????????2KP,NT??????2KP:familylang=en,ja,ja > NtMotoyaKyotai,NT???g????????2????,NT??????2??:familylang=en,ja,ja Those almost look like SJIS encoded names, but they don't make sense when interpreted in that way. I think we can assume that whatever encoding was marked in the file was incorrect. > >From what above cases, as far as familyname is concerned, I must to > get capability to select localized name. What I'd suggest is, > > * Preparing env. variables FC_LANG, FC_CTYPE I don't see how these are better than LANG and LC_CTYPE, aside from accepting a list of allowed languages. We could permit that as an extension for unusual cases, but then we'd want to also use those in the font preference mechanism which does currently use LANG, LC_CTYPE and LC_ALL. In any case, I want to do this in a new API which would accept an optional application-provided language tag and return the 'best' name from the available list (or perhaps sort the available names according to some metric). Attempting to overload the existing API with this new semantic seems like a bad idea. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050226/67b6e517/attachment.pgp
