Re: Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Roozbeh Pournader]

>  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:
http://oreilly.com/catalog/9780596514471/

>  1. the way Unicode.org decided it would be a good idea to have them
>  share codepoints ("Han unification"), so CJK packagers compete with each
>  other to make their pet font the default 
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.

Font packagers competing with each other in pushing their fonts is not
acceptable either. If that doesn't stop, we should perhaps centralize
our fontconfig configuration files to avoid such fontconfig wars.

On a separate note, it wasn't unicode.org who decided to unify Han
characters. It was a consensus effort, supported by various national
standardization bodies, including those of China, Japan, and Korea.
Please don't spread FUD ;-) You can read about the actual history of
Han Unification here:

http://unicode.org/versions/Unicode5.0.0/appE.pdf

Roozbeh

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Qianqian Fang]

> > 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 consortium proposed.

> > so CJK packagers compete with each other to make their pet font
> the default
> >      
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
language preference, and it falls into a mixed situation where both the
context language and the fall-back font sequence in fontconfig (likely
65-nonlatin) play together to determine the font to select, and the 
results are
messy. It would have been better if one of the Han variants is the default
when this happens, for example, the one that covers the most unicode code
points, at least, all the characters will have uniform font styles, rather
than the mosaics from many CJK fonts.

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Jens-Ulrik Petersen]

I think the particular problem here under F10 is

https://bugzilla.redhat.com/show_bug.cgi?id=485562

----- "Qianqian Fang" <fangqq(a)gmail.com&gt; 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
>  language preference, and it falls into a mixed situation where both
>  the
>  context language and the fall-back font sequence in fontconfig
>  (likely
>  65-nonlatin) play together to determine the font to select, and the 
>  results are
>  messy. It would have been better if one of the Han variants is the
>  default
>  when this happens, for example, the one that covers the most unicode
>  code
>  points, at least, all the characters will have uniform font styles,
>  rather
>  than the mosaics from many CJK fonts. 
Hmm, maybe we should define PANGO_LANGUAGE for non CJK locale, but to which value.  Well
guess most points would be zh? ;)

Jens

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Nicolas Mailhot]

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 not happen is we have a lot more
CJK packages than Arabic packages (and no Fraktur packages that I know
of).

>  Font packagers competing with each other in pushing their fonts is
> not
>  acceptable either. If that doesn't stop, we should perhaps centralize
>  our fontconfig configuration files to avoid such fontconfig wars. 
It's not really a centralizing problem. If we had a clear "official"
clean way to write fontconfig cjk rules I'd happily crack down on
packagers not using them. Right now we haven't really, so I refrain.
Nevertheless CJK fonts easily account for 80% of our reported font
bug.

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, I'm not even sure this is clear to anyone but the concerned
packagers. And every time I open a CJK fontconfig file I see magic of
the blackest sort.

Sincerely,

-- 
Nicolas Mailhot

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[AKanda]

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 I force the system with vlgothic is also good.

The problem would be "DejaVu Sans" (think)

(sorry for my english)

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Ben Laenen]

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 if I write with vlgothic it's good.
>
>  Also, if I force the system with vlgothic is also good.
>
>  The problem would be "DejaVu Sans" (think) 
That would be very awkard since DejaVu doesn't have any CJK glyphs.

What's happening is that for your "Sans" font selection, it will get 
translated by rules in the fontconfig configuration files (basically a 
list of fonts telling what to use for "Sans"), and it chooses the first 
font in the list that's capable of showing the displayed script. So in 
your case it chooses DejaVu to display Latin, and when it encounters 
CJK glyphs, fontconfig has no idea whether it's Chinese or Japanese, 
and so selects the first font in the list with the necessary glyphs, 
and that's a Chinese font.

The solution is to move your VLGothic font above the Chinese font in 
that list.

Greetings
Ben

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Roozbeh Pournader]

On Tue, Feb 24, 2009 at 12:23 AM, Nicolas Mailhot
<nicolas.mailhot(a)gmail.com&gt; wrote:
>  I suspect the only reason that does not happen is we have a lot more
>  CJK packages than Arabic packages (and no Fraktur packages that I know
>  of). 
:-)

You may be very right.

>  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, I'm not even sure this is clear to anyone but the concerned
>  packagers. And every time I open a CJK fontconfig file I see magic of
>  the blackest sort. 
So, would you recommend a process and some high priorities?
fedora-i18n has a stake in this too, and we may be able to ask them
for some help.

(I would love to help in doing this, but I don't have much experience
with either CJK or fontconfig rules. I will jump in whenever Unicode
skills were called in. I also have a copy of the tome I mentioned
before, but haven't really spent much time with it.)

Roozbeh

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Caius Carlos CHANCE]

-----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, I'm not even sure this is clear to anyone but the concerned
> > packagers. And every time I open a CJK fontconfig file I see magic of
> > the blackest sort. 
I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10)
which priority of such Chinese fonts are at higher priority in condition
of "zh" (Chinese) locale.

The fedora 10 patch will be pushed to update-testing very soon.

- - kaio

- --
Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com
JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmkyAYACgkQmo+B7bGj5dJ0LACfQsMIHrQb4oxv0xrn7ULeGwGc
> nyEAnAx77c1Yo2NQzaStpbX0F4/5jgK9
> =C40I
> -----END PGP SIGNATURE-----

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Caius Carlos CHANCE]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Caius "kaio" Chance wrote:
>  I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10)
>  which priority of such Chinese fonts are at higher priority in condition
>  of "zh" (Chinese) locale.
>  
>  The fedora 10 patch will be pushed to update-testing very soon. 
http://kojipkgs.fedoraproject.org/packages/cjkunifonts/0.2.20080216.1/11....

http://koji.fedoraproject.org/koji/buildinfo?buildID=86225

- - kaio

- --
Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com
JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmkynsACgkQmo+B7bGj5dIHeQCeMnBDdu0tyMDRnz1HakdYJpvB
> AzQAn0L62dgbP1rlN2qhjB8VPHu6Z+Sc
> =E5jL
> -----END PGP SIGNATURE-----

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Qianqian Fang]

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 them cleanly.
> >> Right now, I'm not even sure this is clear to anyone but the concerned
> >> packagers. And every time I open a CJK fontconfig file I see magic of
> >> the blackest sort.
> >>       
>
>  I have patched the cjkuni-fonts on rawhide (and cjkunifonts on f10)
>  which priority of such Chinese fonts are at higher priority in condition
>  of "zh" (Chinese) locale.
>     
I think this basically means the Japanese fonts are now having higher
priorities under non-CJK locales, is this really what we want?

 
>  The fedora 10 patch will be pushed to update-testing very soon.
>
>  - - kaio
>
>  - --
>  Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com
>  JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.9 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> >
> >  iEYEARECAAYFAkmkyAYACgkQmo+B7bGj5dJ0LACfQsMIHrQb4oxv0xrn7ULeGwGc
> >  nyEAnAx77c1Yo2NQzaStpbX0F4/5jgK9
> >  =C40I
> >  -----END PGP SIGNATURE----- 
>  --
>  Fedora-i18n-list mailing list
>  Fedora-i18n-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-i18n-list
>
>
>
>

Problem : japanese-fonts (vlgothic-fonts-20090204-2.fc10)

[Akira TAGOH]

> >>>> On Wed, 25 Feb 2009 01:36:17 -0500,
> >>>> "QF" == Qianqian Fang <fangqq(a)gmail.com&gt; 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 really wants to see a text with proper font,
they need to set PANGO_LANGUAGE with the appropriate locales
ordered or embed Pango attributes in text for GNOME.

However right now cjkunifonts fontconfig config affected
Japanese desktop too because current fontconfig policy in
Fedora suggests having a recipe to override default
substitution lists for specific locale and all of Japanese
fonts has already followed these rules, but cjkunifonts
didn't and fontconfig reads it prior to Japanese fonts'.

--
Akira TAGOH