[opensuse-m17n] Discussion: Porting noto font family to our openSUSE
Hi, all: As we know, openSUSE leap 42.1 locale zh_* has changed the default fonts to google-noto, and make Chinese openSUSE's font render much beautiful. As the description in wiki page: Noto is a font family designed to cover all the scripts encoded in the Unicode standard. It is designed with the goal of achieving visual harmony (e.g., compatible heights and stroke thicknesses) across multiple languages/scripts. Commissioned by Google, the font is licensed under the SIL Open Font License. Until September 2015, the fonts were under the Apache License 2.0. I propose to port noto font family to other language to openSUSE desktop as default font. But I'm wondering, is there any country or area improper to use it? Thank you ! -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, 27 Jul 2016 14:45:39 +0200, ZhaoQiang wrote:
For a bit more information: this inquiry came from a bug report for SLED12-SP2. Yes, we have already google-noto-fonts and noto-sans-cjk-fonts packages. However, noto-sans-cjk-fonts has the line Provides: locale(zh_CN;zh_SG;zh_TW;zh_HK;zh_MO) thus only Chinese locales will install this as default. For making noto-sans-cjk font to be installed automatically on Japanese and Korean locales, we'd need to put "ja" and "ko" there. However, there is one pintfall: noto sans CJK fonts are always prepended to the list of "sans" aliases, so once when this package is installed, this will be used in prior to other fonts as a system-default font. Also note that the Provides() in the spec file plays a role as "recommends" (or more accurately, other way round -- the package is recommended on the corresponding running locale). Hence, adding to Provides() shouldn't influence on the already installed system, unless you do zypper install-recommends or such. So, if anyone has a strong objection against adding ja and ko locales to Provides() of noto-sans-cjk -- so that this package will *not* be drug onto a fresh installation, please speak up. I don't guess there won't be so many people actually against it, but we'd like to have a consensus before going forward. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi Noto font family is really nice for printing purpose. However, as far as I know, there are some concerns about Noto Sans CJK JP - old fontconfig (on Leap 42.1) wrongly regards medium (not regular) as a default weight. Thus, fonts looks thicker on many applications. - cause too big spaces on Plasma Kick off widget (the old launcher) - it seems that Noto Sans requires sub-pixel rendering for its expected rendering result. As you know sub-pixel rendering is disabled on openSUSE - I think we should split the google-noto-sans-* packages into two or more packages since normal user does not need all weight of Noto Sans. The size of the packages are really huge. Best regards, Fuminobu Takeyama On 2016/07/27 22:31, Takashi Iwai wrote:
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, 27 Jul 2016 16:12:35 +0200, Fuminobu TAKEYAMA wrote:
Thanks for the quick checks!
- old fontconfig (on Leap 42.1) wrongly regards medium (not regular) as a default weight. Thus, fonts looks thicker on many applications.
This shouldn't be a big issue. The update is for only OBS M17N:fonts and TW. If anyone wants to fix the issue on Leap 42.1, user can fetch fontconfig.rpm from OBS M17N repo, too.
- cause too big spaces on Plasma Kick off widget (the old launcher)
Hm, I didn't know of this. Could you give a pointer? Does this happen on TW version, right? I noticed that the noto sans font glyph is actually larger than other fonts (e.g. IPA). That's why I don't use noto sans on my own desktop. But it shouldn't be too big. Plasma kickoff should be fixed, if any.
- it seems that Noto Sans requires sub-pixel rendering for its expected rendering result. As you know sub-pixel rendering is disabled on openSUSE
Well, it might be sub-optimal, but it doesn't look too bad even without subpixel rendering to my eyes. Or maybe I need to buy new glasses. If the fonts are supposed not to be used without subpixel rendering, we should avoid the fonts, of course. But I don't think it's considered so?
FWIW, the addition of Provides() is only to noto-sans-cjk-fonts, and this package contains only a single NotoSansCJK.ttc (and a fontconfig file to prepend the sans list). Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
I will make images for comparing the fonts. (maybe next week)
I remind that now. It was separated but now uses ttc file. The ttc file contains 7 weights of CJK JP/KR/TC/SC and requires about 100 MB. It would be better to save space that only JP/KR/TC/SC regular and bold are bundled into one ttc file, I think. # the package name would be google-noto-sans-cjk-basic-weight-fonts Fuminobu TAKEYAMA (ftake) On 2016/07/27 23:26, Takashi Iwai wrote:
Hi, Actually there's a known problem for using only one .ttc font. I used fontconfig magic to prepend Noto Sans CJK based on locales. So when you view Chinese under an English locale, which is quite common eg in browsers, the Chinese will be displayed using Noto Sans Japanese varaiant, which is not able to get fixed if we use a single .ttc font. It is the same for all other CJK languages except Japanese. Marguerite -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, 04 Aug 2016 02:52:54 +0200, Marguerite Su wrote:
Well, it's a problem of Unicode in general. The issue may happen no matter whether ttc or not. Japanese is chosen just because of the alphabet order in this case. If the web page specifies properly the language attribute, the rendering should be fine. But most of web pages don't do the right thing :) Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, Aug 4, 2016 at 2:43 PM, Takashi Iwai <tiwai@suse.de> wrote:
Yes...it's not ttc or ttf, but "one" ttc or "many" ttcs. If we use separated ttcs, you can install Chinese variant and see Chinese right if you see Chinese not displayed under any locale. But if we use one ttc, you will not see Chinese right even if you have installed Chinese variant in English (which is not covered by the tweak and should not be covered) Because the locale-based tweak and the unicode problem. So I think this might be a shortcoming for this topic. Because users will not get the behavior they want in some cases.
Most of the web pages will only specify "sans-serif" and let the system decide. The language attribute is not possible at all, because any web page may have something English...A good part of fontconfig is that you can use a font to display English and fallback to the other when CJK characters come out. This technology is commonly used in Windows/Mac/Linux... Marguerite -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Fri, 05 Aug 2016 16:33:11 +0200, Marguerite Su wrote:
And if you install both Chinese and Japanese fonts? The problem returns again. See, it's no solution at all.
IMO, the problem is that the implicitly preferred locale hasn't been told to the system. If you run a system in English locale but still prefer the Chinese letters over other CJK, how can the system know of it? We need to inform it somehow. The package selection works partially, but it gets broken again if multiple language fonts are installed. Maybe we can another item, e.g. $CJK_PREFERRED_LOCALE in /etc/sysconfig/fonts-config? If this is set, it can be referred by a fontconfig snippet in addition to the current locale check. Adding Petr to Cc about this idea.
Well, you can set the language attribute to specific blocks in HTML, too. The language isn't necessarily unique in the whole page.
Yes, and this should work only if set up properly. As said, the missing piece is the information which locale is implicitly preferred. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Am 05.08.2016 um 16:52 schrieb Takashi Iwai:
This is actually a really big problem. Most commonly seen cases are a) CJK system with English b) English system with ONE CJK script but try to use English system with two CJK scripts simultaneously or maybe another western, not english system with two CJK languages... I don't even want to imagine non-latin scripts with CJK languages.
I would actually like something like that. I tried to change the CJK font priority on a German linux system, but after some time gave up. It was really not easy... especially if you are no fontconfig expert. -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi,
I will make images for comparing the fonts. (maybe next week)
Please look at these pictures: [1] http://blog.geeko.jp/wp-content/uploads/2016/08/font-comparison-ft-view.png [2] http://blog.geeko.jp/wp-content/uploads/2016/08/font-comparison-gnome-shell.... [3] http://blog.geeko.jp/wp-content/uploads/2016/08/font-comparison-plasma.png # Article in Japanese http://blog.geeko.jp/ftake/1398 I compared three fonts: - Noto Sans CJK JP (from Leap repository) - IPA PGothic (current default for Japanese) - Migu 1C According to the result of ft-view [1], - Noto Sans and Migu 1C have larger line height than IPA PGothic. - When hinting is enabled, glyphs of Noto Sans looks a bit vertically stretched - For small pixel size, Noto Sans does not improve drastically Next, I compared those fonts on Nautilus [2] and Plasma Kickoff [3]. Even though Noto Sans and Migu 1C have almost the same height, Noto Sans makes larger margins than Migu 1C. On Plasma Kickoff [3], the margin is too big; The height of Kickoff menu is over 768 px. Fuminobu TAKEYAMA (ftake) On 2016年07月30日 00:51, Fuminobu TAKEYAMA wrote:
Hi Takeyama san: I have double check about your snapshot and suggestions. Not sure if this is a big problems, maybe this because I'm not using Japanese, But it truly doesn't cause any uncomfortable to me. Another problem is Noto will cover more characters than other fonts. we won't see much blank in document if we turn to google-noto. And google-noto is a fast developed project, some of the problems can be solve in future. In my opinion, only if there are some problem which proved can not be fixed , and at the same time, it's very important to us, then we will denied it. Such as the design problem. Any new feature for a distribution will cause some pan in a short time, But if the direction is correct, It's benefit will always large than the cost for us. Zhao Qiang
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
I am testing Noto Sans CJK on my daily use laptop. The line height is more problematic than I expected. For example, as shown the screen shot of Plasma kick off menu, we need change minimal screen resolution. During writing this mail, the spaces between lines are too big. BTW, the width of Hiragana and Katakana might cause another problem. Although we have been used proportional (variable) width for those characters for screens (UIs), Noto Sans provides fixed width glyphs. # Japanese consume more horizontal spaces for ICT words than Chinese.
Another problem is Noto will cover more characters than other fonts. we won't see much blank in document if we turn to google-noto.
I think on Linux desktop, that is *not* the problem Noto Sans resolves. Due to font-config, if a glyph is not provided by the current font, font-config can pick glyphs from another font. The problem Noto Sans resolves is, as described on its website, "to support all languages with a harmonious look and feel." I know this is problem especially when reading a document written in multiple languages. Moreover, if users who mainly use English, for example, and installed CJK fonts other than Noto Sans then the CJK fonts is used for English words. Using Noto Sans globally will resolve these issues. I will ask Japanese community to try Noto Sans CJK JP and send feedback. Fuminobu TAKEYAMA (ftake)
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, 27 Jul 2016 14:45:39 +0200, ZhaoQiang wrote:
For a bit more information: this inquiry came from a bug report for SLED12-SP2. Yes, we have already google-noto-fonts and noto-sans-cjk-fonts packages. However, noto-sans-cjk-fonts has the line Provides: locale(zh_CN;zh_SG;zh_TW;zh_HK;zh_MO) thus only Chinese locales will install this as default. For making noto-sans-cjk font to be installed automatically on Japanese and Korean locales, we'd need to put "ja" and "ko" there. However, there is one pintfall: noto sans CJK fonts are always prepended to the list of "sans" aliases, so once when this package is installed, this will be used in prior to other fonts as a system-default font. Also note that the Provides() in the spec file plays a role as "recommends" (or more accurately, other way round -- the package is recommended on the corresponding running locale). Hence, adding to Provides() shouldn't influence on the already installed system, unless you do zypper install-recommends or such. So, if anyone has a strong objection against adding ja and ko locales to Provides() of noto-sans-cjk -- so that this package will *not* be drug onto a fresh installation, please speak up. I don't guess there won't be so many people actually against it, but we'd like to have a consensus before going forward. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi Noto font family is really nice for printing purpose. However, as far as I know, there are some concerns about Noto Sans CJK JP - old fontconfig (on Leap 42.1) wrongly regards medium (not regular) as a default weight. Thus, fonts looks thicker on many applications. - cause too big spaces on Plasma Kick off widget (the old launcher) - it seems that Noto Sans requires sub-pixel rendering for its expected rendering result. As you know sub-pixel rendering is disabled on openSUSE - I think we should split the google-noto-sans-* packages into two or more packages since normal user does not need all weight of Noto Sans. The size of the packages are really huge. Best regards, Fuminobu Takeyama On 2016/07/27 22:31, Takashi Iwai wrote:
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, 27 Jul 2016 16:12:35 +0200, Fuminobu TAKEYAMA wrote:
Thanks for the quick checks!
- old fontconfig (on Leap 42.1) wrongly regards medium (not regular) as a default weight. Thus, fonts looks thicker on many applications.
This shouldn't be a big issue. The update is for only OBS M17N:fonts and TW. If anyone wants to fix the issue on Leap 42.1, user can fetch fontconfig.rpm from OBS M17N repo, too.
- cause too big spaces on Plasma Kick off widget (the old launcher)
Hm, I didn't know of this. Could you give a pointer? Does this happen on TW version, right? I noticed that the noto sans font glyph is actually larger than other fonts (e.g. IPA). That's why I don't use noto sans on my own desktop. But it shouldn't be too big. Plasma kickoff should be fixed, if any.
- it seems that Noto Sans requires sub-pixel rendering for its expected rendering result. As you know sub-pixel rendering is disabled on openSUSE
Well, it might be sub-optimal, but it doesn't look too bad even without subpixel rendering to my eyes. Or maybe I need to buy new glasses. If the fonts are supposed not to be used without subpixel rendering, we should avoid the fonts, of course. But I don't think it's considered so?
FWIW, the addition of Provides() is only to noto-sans-cjk-fonts, and this package contains only a single NotoSansCJK.ttc (and a fontconfig file to prepend the sans list). Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
I will make images for comparing the fonts. (maybe next week)
I remind that now. It was separated but now uses ttc file. The ttc file contains 7 weights of CJK JP/KR/TC/SC and requires about 100 MB. It would be better to save space that only JP/KR/TC/SC regular and bold are bundled into one ttc file, I think. # the package name would be google-noto-sans-cjk-basic-weight-fonts Fuminobu TAKEYAMA (ftake) On 2016/07/27 23:26, Takashi Iwai wrote:
Hi, Actually there's a known problem for using only one .ttc font. I used fontconfig magic to prepend Noto Sans CJK based on locales. So when you view Chinese under an English locale, which is quite common eg in browsers, the Chinese will be displayed using Noto Sans Japanese varaiant, which is not able to get fixed if we use a single .ttc font. It is the same for all other CJK languages except Japanese. Marguerite -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, 04 Aug 2016 02:52:54 +0200, Marguerite Su wrote:
Well, it's a problem of Unicode in general. The issue may happen no matter whether ttc or not. Japanese is chosen just because of the alphabet order in this case. If the web page specifies properly the language attribute, the rendering should be fine. But most of web pages don't do the right thing :) Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
participants (5)
-
Fuminobu TAKEYAMA
-
Hans Schmidt
-
Marguerite Su
-
Takashi Iwai
-
ZhaoQiang