ubuntu-translations-coordinators team mailing list archive

[Mingye Wang <arthur2e5@xxxxxxxx>]

Jeff Bai <jeffbai@xxxxxxxx> and I are currently working on a newer
ordering of this file for the CJK part at https://github.com/AOSC-Dev
/aosc-os-abbs/issues/201. Hopefully we will come up with a modernized
version this weekend or so.

We are mainly focused on these points:

* Separate sans (hei), serif (ming/song) and cursive (kai). Like the current git version of the file, we are now only adding strongly monospace (i.e. monospace for non-han parts too) fonts as monospace, but this is actually worth a discussion IFF the font is only going to provide CJK chars. (We know at least FW kanas and hanzi/kanjis are always 1em wide (good), while some hanguls are like .93 em (oops).)
* Font weight matching. Many old CJK serifs (e.g. UMing, SimSun) look too thin to match common serifs, but the TeX community have good fonts to remedy this -- cwTeX and Fandol fonts. We add [kind of prepend, in CJK ranges] these fonts to the list accordingly. As a bonus, these are all FOSS. Some CJK sans on the other hand is too heavy (e.g. SimHei[1]), but now we have Noto Sans CJK/Source Han Sans to remedy this.
* Sans-serif monospace is better than serif monospace, at least for computer screens. Additionally, monospace CJK serifs are often old and have the very-thin-weight issue.

Note that we are not supposed to nor intending to fix any of these
"locale mix" problems like what was shown in the description of
attachment 24321. Locale matching problems should be done via in-browser
detection schemes like html lang tags, with appropriate locale-aware
requests to fc, which hopefully will be handled by other distro-specific
config wiles. We are only trying to make sure the styles of CJK part
matches latin fonts matched for the generic family names, as well as
themselves. (This is actually a terrible problem on MS Windows, where
they consider SimSun a sans-serif.)

(Well, considering the widths of some glyphs like 复 in Japanese fonts
(they are often not actually using the glyphs in the language but using
it as some glyph to be referenced by other glyphs), I will go with TW,
KR or CN fonts as the preferred source of Chinese glyphs. Choosing the
traditional locales is just for "going back the roots and be acceptable
to as many locales as possible". (KR glyphs are kind of old/kangxi-ish-
style -- lack of use lead to lack of evolution.))

[1]: In Chinese, Hei (黑) stands for black. This actually caused some
confusion and resulted in many people calling bold weights "Hei".

I have no idea on how to fix the bad "ja" language tags in Chinese fonts
though. (why are they trying to <s>eat</s> manage everything?)

-- 
You received this bug notification because you are a member of Ubuntu
Translations Coordinators, which is subscribed to Ubuntu Translations.
Matching subscriptions: Ubuntu Translations bug mail
https://bugs.launchpad.net/bugs/502610

Title:
  Chinese characters unexpectedly switch fonts in WebKit-GTK

Status in Fontconfig:
  Unknown
Status in Ubuntu Software Center:
  Invalid
Status in Ubuntu Translations:
  Fix Released
Status in webkit package in Ubuntu:
  Fix Released

Bug description:
  Ubuntu Software Center 1.1.7, Epiphany 2.28.0, Midori 0.1.9 (Ubuntu
  9.10)

  In WebKit-GTK, Chinese text varies fonts unexpectedly.

  For example, in Ubuntu Software Center's main screen, where the Office department is labelled "办公", "办" is in the WQY font while "公” is in the Ukai font. And where the Universal Access department is labelled "全局访问", the "全局" and "访问" are in different fonts.
      http://launchpadlibrarian.net/37382124/Lesson07_images_033.png

  You can see the same problem in the Epiphany and Midori browsers, which also use WebKit-GTK, by copying and pasting this into their address field:
      data:text/html,<meta%20http-equiv="Content-Type"%20content="text/html;%20charset="utf-8">办公%20全局访问

  Firefox, AbiWord, and OpenOffice.org do not have the same problem.
  Interestingly, neither does Chromium 4.0.293.0 (35769, from the
  Chromium daily PPA), which suggests that it may be a WebKit-GTK bug
  that has been fixed since the version packaged in Ubuntu 9.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/fontconfig/+bug/502610/+subscriptions