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: phuang redhat com, petersen redhat com, fundawang mandriva org, abelcheung gmail com, fedora-fonts-list redhat com, gtk-i18n-list gnome org
- 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: Fri, 21 Dec 2007 11:02:01 -0500
On Fri, 2007-12-21 at 09:12 +0900, mpsuzuki hiroshima-u ac jp wrote:
> >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.
>
> I see. Hearing "people just avoid it" is quite interesting.
As I said, it's not just technical. It's bad style to start a
Persian/Arabic paragraph with a Latin word.
> >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.
>
> Yes. Do you think it's worse than contextual font switching?
I think rendering single-script text correctly is more important, yes.
If you have plain text in one script, it should only use the preferred
font of that script. Can't compromise here.
> I don't think so. But it's because my fonts have varied/inconsistent
> baselines and heights (and their inconsistency makes the contextual
> font switching quite ugly), so my disagree is not so strong at present.
>
> Anyway, your mention on bidi reminded me that binding a fixed font
> to COMMON characters may confuse bidi glyph shaping of punctuation.
> If so, it would be problematic and binding should be disabled even
> if it's possible. Oops.
No, bidi reordering is done independent of font selection. Those are
completely separate processes.
> >> >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.
>
> OK, I will try to setup ~/.fonts.conf.
I don't think that would do it. Just set it in gnome-font-properties.
> It seems that my
> request (binding a same font to COMMON character, at
> least in Latin & CJK context) can be realized by it
Not exactly. Hardcoding a font in your fontconfig config to always
return a certain font as the first font is not a good idea, and is
actually what started this thread at the beginning.
> - so it's off-topic to this list? Should I move to fontconfig?
I don't think forcing to use the same font for COMMON characters is
really a solution. The simplest solution for the case you showed is to
use a font that has both Japanese and Latin glyphs (plus all the
punctuation). Again, what started this thread was that the CJK font had
Latin glyphs, but crappy ones.
> Anyway, thank you for enlightening me.
>
> 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]