On Wed, 25 Feb 2009 01:36:17 -0500,
QF == Qianqian Fang fan...@gmail.com wrote:
QF I think this basically means the Japanese fonts are now
QF having higher
QF priorities under non-CJK locales, is this really what we
QF want?
Current fontconfig policy doesn't really helps in this
case. if one
Le Mar 24 février 2009 05:39, Roozbeh Pournader a écrit :
I can't relate these two. By the same reasoning, Fraktur fonts would
compete with modern Latin fonts, Urdu fonts would compete with Arabic
fonts, and Hindi fonts would compete with Marathi fonts.
I suspect the only reason that does
Jens Petersen a écrit :
I think the particular problem here under F10 is
https://bugzilla.redhat.com/show_bug.cgi?id=485562
Hello,
In OpenOffice (for exemple), I have always written in Japanese with the
default font (DejaVu Sans .)
But in fact if I write with vlgothic it's good.
Also, if
On Tuesday 24 February 2009, AKanda wrote:
Jens Petersen a écrit :
I think the particular problem here under F10 is
https://bugzilla.redhat.com/show_bug.cgi?id=485562
Hello,
In OpenOffice (for exemple), I have always written in Japanese with
the default font (DejaVu Sans .)
But in fact
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roozbeh Pournader wrote:
It would be nice if our intended priorities and fontconfig settings
for CJK fonts were documented somewhere (for every concerned locale).
Then I could pester Behdad so he tells us how to achieve them cleanly.
Right now,
Caius kaio Chance wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roozbeh Pournader wrote:
It would be nice if our intended priorities and fontconfig settings
for CJK fonts were documented somewhere (for every concerned locale).
Then I could pester Behdad so he tells us how to achieve
Le jeudi 19 février 2009 à 20:30 +0100, AKanda a écrit :
Hello,
Hi Akanda,
The last update for VLgothicsvlgothic-fonts-20090204-2.fc10.noarch
is perhaps not good. (Install by yum.)
Sorry for the delay, I was hoping other CJK users would answer, I don't
use CJK myself.
Chinese, Korean and
Chinese, Korean and Japanese fonts are an old source of pain for font
packagers, due to:
... CJK information processing being very hard to do correctly. See
Ken Lunde's amazing 900-page tome, CJKV Information Processing,
which recently appeared in its second edition:
1. the way Unicode.org decided it would be a good idea to have them
share codepoints (Han unification),
Using unified code points to represent Han glyphs is nothing wrong,
the only issue is the current fonts and fontconfig are not capable
of distinguishing the z-variants, as Unicode
I think the particular problem here under F10 is
https://bugzilla.redhat.com/show_bug.cgi?id=485562
- Qianqian Fang fan...@gmail.com wrote:
I think it is quite the opposite: this happens most often when people
are trying to read CJK text under non-CJK locales. Pango does not
assume
10 matches
Mail list logo