Re: [gtk-i18n-list] Re: On CJK font selection (was Re: [Fwd: Re: Request for review and advice on wqy-bitmap-fonts fontconfig settings])
- From: Behdad Esfahbod <behdad behdad org>
- To: mpsuzuki hiroshima-u ac jp
- Cc: gtk-i18n-list gnome org, petersen redhat com, fundawang mandriva org, abelcheung gmail com, fedora-fonts-list redhat com, phuang redhat com
- Subject: Re: [gtk-i18n-list] Re: On CJK font selection (was Re: [Fwd: Re: Request for review and advice on wqy-bitmap-fonts fontconfig settings])
- Date: Thu, 20 Dec 2007 18:40:29 -0500
On Fri, 2007-12-21 at 08:21 +0900, mpsuzuki hiroshima-u ac jp wrote:
> Thank you very much!
You are very welcome.
[...]
> > - In image 2', you are running under Japanese locale, you type a
> >COMMON character ('[') only, Pango assumes you are going to type
> >Japanese text, your preferred Japanese font has a glyph for '[', so
> >Pango uses it, hoping that it will use the same font when you enter
> >Japanese text.
>
> Oh! It corrects my misunderstanding. I was misunderstanding as
> only '[' was given, the text was recognized as a Latin because
> '[' is included in ASCII. Now I understand that ASCII numerical
> digits are also COMMON character.
Yes.
> >So, the issue comes down to the fact that:
> >
> > - It's unexpected to enter Latin under Japanese locale.
> >
> > - You have a COMMON character at the beginning of the line.
> >
> > - Your Japanese and Latin fonts have different heights.
>
> I see. The first clause is quite important. I guess, inputting
> Latin text under Arabic locale might be possible but irregular
> (right guessing? please let me know), but an insertion of
> Latin text (to be more correctly, I mean a string of ASCII
> alphabets) under Japanese locale is popular, especially text
> around information technology. For example, please check the
> website of Japanese Standards Association http://www.jsa.or.jp/
Arabic is like Japanese in that regard, no difference. I actually see
that coming, should have clarified. By unexpected, I mean it's not the
most likely event. Japanese text coming is more expected.
That said, we don't have that in issue as much in Arabic because it's
considered bad writing to start an Arabic/Persian paragraph with an
English word written in Latin. It also screws bidirectional code in
Pango and you end up with a left-to-right paragraph (because that's what
it looks like from your text), so people just avoid it.
> >One way one may suggest is that Pango should reserve a minimum line
> >height that is enough to fit the default Japanese font, because it's
> >running under Japanese locale after all. That would fix the jump from
> >3' to 4', but makes English-only paragraphs look very ugly and badly
> >spaced vertically, so that's not an option either.
> >
> >The jump from 2' to 3' can't be fixed. I already proved that. If one
> >fixes it, it would introduce the bug that '[' followed by a Japanese
> >character will choose a separate fonts for those chars, OR, that font
> >used for '[' will change when you type a Japanese char.
>
> Umm. Is it possible for Pango to bind COMMON characters to single
> font? I understand the font switching in my example is caused by
> the fact that the appropriate font to show COMMON character is
> determined by its context. If the font to show COMMON character is
> fixed to single font, my problem will be slightly better although
> the line height shifting still occurs.
But then when rendering a Japanese only text, all the punctuation marks
will be rendered using a different font! Now imagine that in a
monospace text, with bitmap Japanese font and non-bitmap punctuation
font.
> >It's as simple as this: Pango can't know what you are going to type next.
> >It can just guess, and it's guessing pretty good. It's just not reading
> >your mind yet :).
>
> Indeed. I wish anybody can implement it in Pango2 :-)
That's already on my wishlist. I may as well open a bug for it.
> >I have two suggestions for what you can do that may achieve better
> >results for you.
> >
> > - Run under LC_LANG=en_US LC_MESSAGES=ja_JA
> >
> > - Choose a non-generic font family in gedit. That is, something other
> >than Sans, Sans-serif, and Monospace.
>
> Oops, it's too application specific...
No. Give it a try. It should have the effect you asked for. All
punctuation should be chosen from the non-generic font you choose. I
said do it in gedit just to test, otherwise it's nothing specific to
gedit, that's how fontconfig works. Lets see:
[behdad behdad berlin-fest]$ fc-match 'sans:lang=en' --sort | head -4
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-ExtraLight.ttf: "DejaVu Sans" "ExtraLight"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
luxisr.ttf: "Luxi Sans" "Regular"
[behdad behdad berlin-fest]$ fc-match 'sans:lang=ja' --sort | head -4
sazanami-gothic.ttf: "Sazanami Gothic" "Regular"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-ExtraLight.ttf: "DejaVu Sans" "ExtraLight"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
[behdad behdad berlin-fest]$ fc-match 'DejaVu Sans:lang=en' --sort |
head -4
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-ExtraLight.ttf: "DejaVu Sans" "ExtraLight"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
luxisr.ttf: "Luxi Sans" "Regular"
[behdad behdad berlin-fest]$ fc-match 'DejaVu Sans:lang=ja' --sort |
head -4
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-ExtraLight.ttf: "DejaVu Sans" "ExtraLight"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
sazanami-gothic.ttf: "Sazanami Gothic" "Regular"
That is, if you ask for a non-generic font (DejaVu Sans here) for
language Japanese, it first gives you DejaVu Sans (even if it doesn't
cover Japanese), then the best Japanese font available.
> Regards,
> mpsuzuki
--
behdad
http://behdad.org/
...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning. -- Matt Welsh
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]