Discussion:
[opensuse-m17n] Discussion: Porting noto font family to our openSUSE
ZhaoQiang
2016-07-27 12:45:39 UTC
Permalink
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Takashi Iwai
2016-07-27 13:31:36 UTC
Permalink
On Wed, 27 Jul 2016 14:45:39 +0200,
Post by ZhaoQiang
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.
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?
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Fuminobu TAKEYAMA
2016-07-27 14:12:35 UTC
Permalink
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
Post by Takashi Iwai
On Wed, 27 Jul 2016 14:45:39 +0200,
Post by ZhaoQiang
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.
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?
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Takashi Iwai
2016-07-27 14:26:12 UTC
Permalink
On Wed, 27 Jul 2016 16:12:35 +0200,
Post by Fuminobu TAKEYAMA
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
Thanks for the quick checks!
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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?
Post by Fuminobu TAKEYAMA
- 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.
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
Post by Fuminobu TAKEYAMA
Best regards,
Fuminobu Takeyama
Post by Takashi Iwai
On Wed, 27 Jul 2016 14:45:39 +0200,
Post by ZhaoQiang
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.
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?
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Fuminobu TAKEYAMA
2016-07-29 15:51:09 UTC
Permalink
Post by Takashi Iwai
Post by Fuminobu TAKEYAMA
- 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 will make images for comparing the fonts. (maybe next week)
Post by Takashi Iwai
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).
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)
Post by Takashi Iwai
On Wed, 27 Jul 2016 16:12:35 +0200,
Post by Fuminobu TAKEYAMA
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
Thanks for the quick checks!
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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?
Post by Fuminobu TAKEYAMA
- 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.
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
Post by Fuminobu TAKEYAMA
Best regards,
Fuminobu Takeyama
Post by Takashi Iwai
On Wed, 27 Jul 2016 14:45:39 +0200,
Post by ZhaoQiang
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.
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?
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Marguerite Su
2016-08-04 00:52:54 UTC
Permalink
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Takashi Iwai
2016-08-04 06:43:17 UTC
Permalink
On Thu, 04 Aug 2016 02:52:54 +0200,
Post by Marguerite Su
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.
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Marguerite Su
2016-08-05 14:33:11 UTC
Permalink
Post by Takashi Iwai
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.
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.
Post by Takashi Iwai
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 :)
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Takashi Iwai
2016-08-05 14:52:09 UTC
Permalink
On Fri, 05 Aug 2016 16:33:11 +0200,
Post by Marguerite Su
Post by Takashi Iwai
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.
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)
And if you install both Chinese and Japanese fonts? The problem
returns again. See, it's no solution at all.
Post by Marguerite Su
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.
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.
Post by Marguerite Su
Post by Takashi Iwai
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 :)
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...
Well, you can set the language attribute to specific blocks in HTML,
too. The language isn't necessarily unique in the whole page.
Post by Marguerite Su
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...
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Hans Schmidt
2016-08-05 18:24:46 UTC
Permalink
Post by Takashi Iwai
On Fri, 05 Aug 2016 16:33:11 +0200,
Post by Marguerite Su
Post by Takashi Iwai
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.
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)
And if you install both Chinese and Japanese fonts? The problem
returns again. See, it's no solution at all.
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.
Post by Takashi Iwai
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.
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Fuminobu TAKEYAMA
2016-08-20 07:52:23 UTC
Permalink
Hi,
Post by Fuminobu TAKEYAMA
I will make images for comparing the fonts. (maybe next week)
Please look at these pictures:
[1]
Loading Image...
[2]
Loading Image...
[3]
Loading Image...
# 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)
Post by Fuminobu TAKEYAMA
Post by Takashi Iwai
Post by Fuminobu TAKEYAMA
- 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 will make images for comparing the fonts. (maybe next week)
Post by Takashi Iwai
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).
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)
Post by Takashi Iwai
On Wed, 27 Jul 2016 16:12:35 +0200,
Post by Fuminobu TAKEYAMA
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
Thanks for the quick checks!
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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?
Post by Fuminobu TAKEYAMA
- 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.
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
Post by Fuminobu TAKEYAMA
Best regards,
Fuminobu Takeyama
Post by Takashi Iwai
On Wed, 27 Jul 2016 14:45:39 +0200,
Post by ZhaoQiang
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.
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?
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
ZhaoQiang
2016-08-23 04:02:37 UTC
Permalink
Post by Fuminobu TAKEYAMA
Hi,
Post by Fuminobu TAKEYAMA
I will make images for comparing the fonts. (maybe next week)
[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.png
[3]
http://blog.geeko.jp/wp-content/uploads/2016/08/font-comparison-plasma.png
# Article in Japanese http://blog.geeko.jp/ftake/1398
- 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)
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
Post by Fuminobu TAKEYAMA
Post by Fuminobu TAKEYAMA
Post by Takashi Iwai
Post by Fuminobu TAKEYAMA
- 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 will make images for comparing the fonts. (maybe next week)
Post by Takashi Iwai
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).
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)
Post by Takashi Iwai
On Wed, 27 Jul 2016 16:12:35 +0200,
Post by Fuminobu TAKEYAMA
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
Thanks for the quick checks!
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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?
Post by Fuminobu TAKEYAMA
- 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.
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
Post by Fuminobu TAKEYAMA
Best regards,
Fuminobu Takeyama
Post by Takashi Iwai
On Wed, 27 Jul 2016 14:45:39 +0200,
Post by ZhaoQiang
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.
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?
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Fuminobu TAKEYAMA
2016-08-28 06:56:56 UTC
Permalink
Post by ZhaoQiang
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.
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.
Post by ZhaoQiang
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)
Post by ZhaoQiang
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
Post by Fuminobu TAKEYAMA
Post by Takashi Iwai
Post by Fuminobu TAKEYAMA
- 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 will make images for comparing the fonts. (maybe next week)
Post by Takashi Iwai
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).
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)
Post by Takashi Iwai
On Wed, 27 Jul 2016 16:12:35 +0200,
Post by Fuminobu TAKEYAMA
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
Thanks for the quick checks!
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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?
Post by Fuminobu TAKEYAMA
- 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.
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
Post by Fuminobu TAKEYAMA
Best regards,
Fuminobu Takeyama
Post by Takashi Iwai
On Wed, 27 Jul 2016 14:45:39 +0200,
Post by ZhaoQiang
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.
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?
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
ZhaoQiang
2016-09-01 08:05:13 UTC
Permalink
Post by Fuminobu TAKEYAMA
Post by ZhaoQiang
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.
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.
Post by ZhaoQiang
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.
I will agree.
If there are great objected in Japanese community, Maybe it means
google-noto fonts don't fit Japan people now.
--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
ZhaoQiang
2016-09-01 09:13:07 UTC
Permalink
Hi All:

Besides Japanese.
Does these have any topic on other language to use google noto fonts in
Asia?
like Vietnamese, Bengal, Thailand, Cambodia, Indonesia, Laos, Iran ...
Post by Fuminobu TAKEYAMA
Post by ZhaoQiang
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.
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.
Post by ZhaoQiang
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)
Post by ZhaoQiang
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
Post by Fuminobu TAKEYAMA
Post by Takashi Iwai
Post by Fuminobu TAKEYAMA
- 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 will make images for comparing the fonts. (maybe next week)
Post by Takashi Iwai
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).
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)
Post by Takashi Iwai
On Wed, 27 Jul 2016 16:12:35 +0200,
Post by Fuminobu TAKEYAMA
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
Thanks for the quick checks!
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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.
Post by Fuminobu TAKEYAMA
- 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?
Post by Fuminobu TAKEYAMA
- 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.
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
Post by Fuminobu TAKEYAMA
Best regards,
Fuminobu Takeyama
Post by Takashi Iwai
On Wed, 27 Jul 2016 14:45:39 +0200,
Post by ZhaoQiang
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.
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?
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org
Loading...