[opensuse-m17n] [RFC]refactor Noto CJK fonts packaging

On Sat, 08 Apr 2017 08:54:29 +0200,

See the rpm changelog, it's Frederic's proposal (now Cc'ed).

Post by Marguerite Su
Japanese glyphs will be always preferred because of its alphabetical order.
This was partially resolved using a specific fontconfig configuration,
which prepends the right order by lang. but this solution didn't take
into consideration for cases like "how to display CJK chars right in a
Latin environment".
We wanted to switch back to the OTF fonts, because it's the only way
to solve all related issues.
But we still didn't have a conclusion for the new font names. eg
google-noto-sans-cjksc-thin-font, google-noto-sans-cjk-thin-fonts,
google-noto-sans-cjk-basic-fonts...
Because we want to split the seldom used weights to save space for the DVD.
2. the attempt to make it default for CJK.
I think this need is growing today because Google released Noto Serif
and gave us the possibility to
replace the ancient "AR PL UMing" fonts
And the only concern for this attempt is: Japanese needs its
Demi-light instead of Regular/Medium weight. I think this can be
handled with fontconfig.
3. the conflicts between Adobe Source Han and Noto CJK
I received a bug report and I knew our packagers also prepared partial
support for CJK (TW and JP) from Source Han side.
This is duplicated actually. Because Google and Adobe actually used
the same source.
The only differences are the name and the Latin part.
Adobe used Source Sans for the Latin part, Google inhibited it (So
the two fonts are identical) but wrote a guideline to ask users to
override the Latin part with Noto Sans/Reboto.
So a new need is triggered. We need to write a new fontconfig to alias
Adobe Source Han by Noto CJK and handle the minor weight differences.
4. the symbol part.
openSUSE still used the old URW "Standard Symbol L" or "OpenSymbol"
from libreOffice to provide symbols.
* Noto provides "Noto Emoji"
* "EmojiOne Color"
* Deepin Linux also released a free symbol font "Deepin OpenSymbol"
which is 100% compatible with Wingdings on Windows
I think it's time to evaluate our choice for symbol fonts again.
#################################################
1. I removed CJK support from google-noto-fonts.
Because we really need a new namespace for CJK.
The scalable value and Provides needed to be handled separately and we
don't want to mess the generate-specfile.sh any more.
2. We need to introduce 4 sources (115mb each) to have the monospace font.
The region specific fonts are small (because each only covers one
region eg Japanese, which means you can't display any Chinese), but
they don't provide monospace fonts.
3. We need a new namespace for Noto Serif CJK.
Because it is new and shouldn't have those Provides/Obsoletes.
4. We need to have new names.
google-noto-(sans|serif)-cjk(sc|tc|ja|kr)-{weight}-font
google-noto-(sans|serif)-cjk(sc|tc|ja|kr)-(mini|full)
to group them again..
And our DVD will include google-noto-sans-cjk(sc|tc|ja|kr)-mini only.
which is about 35mb x 4 = 140mb.
google-noto-sans-cjk
which requires google-noto-sans-cjksc-mini or google-noto-sans-cjkja-mini only.
4.1 Latin people don't care the glyph difference between Chinese and
Japanese that much

Heh, so this answers your question in the beginning "how to display
CJK chars right in a Latin environment"? Answer: "they don't care" :)

Apart from kidding, IMO, we still need a fontconfig help no matter
whether CJK fonts are split or not. The same problem still appears
when you install both Chinese and Japanese fonts on a single system,
for example.

Post by Marguerite Su
4.2 each of the four mini package contains full coverage of CJK, so
you will not want to install
another one if you have one.

Well, but this will still introduce a regression when you upgrade a
system containing the old google-noto-sans-cjk. Basically this meta
package is only for the upgrade, thus we don't need to care much about
the size reduction, i.e. we can take *all* relevant font subpackages.

Post by Marguerite Su
5 Noto Serif CJK
It'll be easy and don't need that detailed split because it's not an
google-noto-serif-cjk{sc|tc|ja|kr}-fonts which contains all seven weights.
Of course, font configurations are still needed for Japanese because
the Demi-light issue.

I find these proposals are sensible and feasible.
As long as the upgrades would work smoothly (and I guess so), I'm for
this movement.

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-08 08:21:34 UTC

Hi, Takashi,

Post by Takashi Iwai
Heh, so this answers your question in the beginning "how to display
CJK chars right in a Latin environment"? Answer: "they don't care" :)
Apart from kidding, IMO, we still need a fontconfig help no matter
whether CJK fonts are split or not. The same problem still appears
when you install both Chinese and Japanese fonts on a single system,
for example.

Yes...we need to use that fontconfig configuration to prepend
sans-serif, serif and monospace.

I think your concern is that one installed:

* noto-sans-cjkjp-*
* noto-sans-cjksc-*

on the same system.

But that assumption isn't real actually...because:

noto-sans-cjkjp-* actually covers all CJK chars...the only difference
is the order of the glyphs,
that is, Chinese displays Kanji in Chinese glyph...

So far I didn't see concern like "I'm Chinese but I want to display
Kanji in Japanese style."

why would you want to install SC if you can display Simplified Chinese?

Of course it may seem duplicate in size.

But so far I didn't see any concern about this, that is:

Why a Japanese wants all the Chinese chars bundled in a Japanese font.

Maybe some years later a Korean will raise such questions...because their
language contains much more difference than the one between JP and Chinese.

Answers to all the questions:

The only way to solve this, is to increase the source size.

That is, use the four 115mb source, just to get monospace fonts.

And use region specific font for JP, KR, SC and TC separately :-)

Post by Takashi Iwai
Well, but this will still introduce a regression when you upgrade a
system containing the old google-noto-sans-cjk. Basically this meta
package is only for the upgrade, thus we don't need to care much about
the size reduction, i.e. we can take *all* relevant font subpackages.

Yes. I think we can think about it later, after we have a testing build :-)

And I'm preparing that testing build.

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-08 09:09:53 UTC

On Sat, 08 Apr 2017 10:21:34 +0200,

Post by Marguerite Su
Hi, Takashi,

Yes...we need to use that fontconfig configuration to prepend
sans-serif, serif and monospace.
* noto-sans-cjkjp-*
* noto-sans-cjksc-*
on the same system.
noto-sans-cjkjp-* actually covers all CJK chars...the only difference
is the order of the glyphs,
that is, Chinese displays Kanji in Chinese glyph...
So far I didn't see concern like "I'm Chinese but I want to display
Kanji in Japanese style."
why would you want to install SC if you can display Simplified Chinese?

Well, suppose you install only noto-sans-cjksc-fonts for Simplified
Chinese locale, and visit a Japanese web page. Would it be shown
correctly with Japanese glyphs even for the CJK unified ideographs?

If my understanding is correct, it wouldn't. When you install
noto-sans-cjkja-fonts in addition and choose it explicitly, then you
can show the Japanese glyphs for such letters properly, though.

Post by Marguerite Su
Of course it may seem duplicate in size.
Why a Japanese wants all the Chinese chars bundled in a Japanese font.
Maybe some years later a Korean will raise such questions...because their
language contains much more difference than the one between JP and Chinese.
The only way to solve this, is to increase the source size.
That is, use the four 115mb source, just to get monospace fonts.
And use region specific font for JP, KR, SC and TC separately :-)

Sorry, I'm confused by the argument here. I supposed that splitting
to subpackages for each region and weight is for reducing the size as
the primary goal?

We might need to reach to some compromise between the reasonable size
reduction and the easy installation / management, but the above
doesn't look well-explaining to me.

BTW, please keep Frederic in the loop, as he's involved in SLE-Desktop
side.

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-08 09:52:43 UTC

Post by Takashi Iwai
Well, suppose you install only noto-sans-cjksc-fonts for Simplified
Chinese locale, and visit a Japanese web page. Would it be shown
correctly with Japanese glyphs even for the CJK unified ideographs?
If my understanding is correct, it wouldn't. When you install
noto-sans-cjkja-fonts in addition and choose it explicitly, then you
can show the Japanese glyphs for such letters properly, though.

I'm not familiar with the terms of Japanese Language...so I'll speak in plain
English.

Part 1:

As you know, there're some common chars in Chinese and Japanese, eg "坂".

If I install SC only, the "坂" on a Japanese website will be displayed
using SC glyphs.

and the Japanese only chars will be displayed using JP glyphs because
Chinese doesn't have them.

It'll be the same for Japanese. the common chars will be displayed with JP.

the Chinese only chars will be displayed using SC, eg: 煚

That is, if you install only one variant, all CJK chars can be shown
and understandable.

But with slightly difference in glyph styles.

Do you want the display effect to be that perfect that every char
needs to be displayed in correct glyph style?

Apparently not. You just want to avoid the "口口口口口" issue for a foreign language.

That's why I said no one will install a second one if the chars have
already been displayed.

Maybe you supposed that the same char eg "我" will be displayed as "我"
in Chinese but "你" in Japanese?

No, there's no such char at all. CJK doesn't have that big difference
for "immigrant" chars.

They look every much similar. The only difference may be, eg:

The rotation degree for "丿" might be slight different, but both will
still be in the same direction.

Part 2:

If you install both.

On a localized system (with zh_CN.UTF-8 or ja.UTF-8 locale):

The Japanese chars will be displayed with JP.

The common chars will be displayed in JP.

The Chinese only chars will be displayed in SC.

because I wrote the language specific prepend policy. JP will be the
preferred one.

And as the common chars are ambiguous for both languages, it'll be
displayed with the preferred font.

Part 3:

If you install both.

On a Latin system (with en_US.UTF-8 locale):

Everything will be displayed in JP except for those Chinese only chars.

Because the prepend policy doesn't and can't cover this case.

Post by Takashi Iwai
Sorry, I'm confused by the argument here. I supposed that splitting
to subpackages for each region and weight is for reducing the size as
the primary goal?
We might need to reach to some compromise between the reasonable size
reduction and the easy installation / management, but the above
doesn't look well-explaining to me.

Yes. split subpackages so we can form a small group for DVD later.

Please read the above "Part 3" first. that is the problem I want to resolve.

Because each of the CJK SC/TC/JP/KR fonts covers for all CJK (just the
order is different,
eg for CJK JP, it'll display texts using JP glyphs first, but CJK SC
will display texts using SC
glyphs first)

If you install two or more of them on a Latin system,

fontconfig will not know which glyph style is preferred, it'll pick
using alphabetical order,
that is JP.

In my assumption (see "Part 1"), no one will install two or more.

A Chinese will pick SC variant by himself because he's familiar with SC only.

And then Japanese can be displayed too.

So there's no motivation for him to install JP again.

But what if that guy installs JP?

Every common chars will be displayed in JP style on his Latin system.

It annoys him because he's Chinese...

Now comes the issue I want to solve.

I want SC to be used for display even he installed both.

Then I can't use NotoSansCJKSC-hinted.zip as source code.

I need to head to the NotoSansSC.zip as source code.

Because that tarball contains Chinese only. and NotoSansJP.zip
contains Japanese only.

They can be used together now. (I still don't know how common chars display yet)

But NotoSansSC.zip doesn't contain the Noto Sans SC Monospace.

There's no such font, if you want a native monospace, you can only use
Noto Sans CJK SC Monospace,
which is in NotoSansCJKSC-hinted.zip.

So:

NotoSansCJKSC-hinted and NotoSansSC.zip must be used as source code both.

But in the final product, noto-sans-cjksc-fonts contains the Noto Sans
SC and Noto Sans CJK SC Monospace.

Every other stuff will be deleted when packaging.

So it will not affect the RPM size, but we need to host more stuff on
OBS and in the .src.rpm.

But since no one raise that need. I think we don't need to be that complicated.

Just assume no one will install two fonts should be okay.

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-09 07:47:00 UTC

On Sat, 08 Apr 2017 11:52:43 +0200,

I'm not familiar with the terms of Japanese Language...so I'll speak in plain
English.
As you know, there're some common chars in Chinese and Japanese, eg "坂".
If I install SC only, the "坂" on a Japanese website will be displayed
using SC glyphs.
and the Japanese only chars will be displayed using JP glyphs because
Chinese doesn't have them.
It'll be the same for Japanese. the common chars will be displayed with JP.
the Chinese only chars will be displayed using SC, eg: 煚
That is, if you install only one variant, all CJK chars can be shown
and understandable.
But with slightly difference in glyph styles.
Do you want the display effect to be that perfect that every char
needs to be displayed in correct glyph style?

Yes. Otherwise it appears strange to me.

Post by Marguerite Su
Apparently not. You just want to avoid the "口口口口口" issue for a foreign language.
That's why I said no one will install a second one if the chars have
already been displayed.

No, it's not the only requirement. Often we *need* to have the
correct output from the web page. Imagine if you want to print out
some official web page written in Chinese (to declare at airport or at
embassy) but with *-cjkjp-fonts: would Chinese government official
accept / prefer such a print out? I doubt it.

The bad thing in this way is that it *apparently* looks OK although
it's incorrect. "Understandable" and "correct" are different.
Just like a difference between "word" in English and "Wort" in
German.

Post by Marguerite Su
Maybe you supposed that the same char eg "我" will be displayed as "我"
in Chinese but "你" in Japanese?

Of course not. Maybe that is another new thing driven by Google's
deep learning ;)

Post by Marguerite Su
No, there's no such char at all. CJK doesn't have that big difference
for "immigrant" chars.
The rotation degree for "丿" might be slight different, but both will
still be in the same direction.
If you install both.
The Japanese chars will be displayed with JP.
The common chars will be displayed in JP.
The Chinese only chars will be displayed in SC.
because I wrote the language specific prepend policy. JP will be the
preferred one.
And as the common chars are ambiguous for both languages, it'll be
displayed with the preferred font.
If you install both.
Everything will be displayed in JP except for those Chinese only chars.
Because the prepend policy doesn't and can't cover this case.

So, when multiple noto-sans-cjk* fonts are installed, the situation is
still very same as OTC, right? Then it means that we *do* still have
the same bug.

There are tons of situations we need such multiple fonts. That is, we
have to fix it properly in anyway via fontconfig.

Yes. split subpackages so we can form a small group for DVD later.
Please read the above "Part 3" first. that is the problem I want to resolve.
Because each of the CJK SC/TC/JP/KR fonts covers for all CJK (just the
order is different,
eg for CJK JP, it'll display texts using JP glyphs first, but CJK SC
will display texts using SC
glyphs first)
If you install two or more of them on a Latin system,
fontconfig will not know which glyph style is preferred, it'll pick
using alphabetical order,
that is JP.
In my assumption (see "Part 1"), no one will install two or more.
A Chinese will pick SC variant by himself because he's familiar with SC only.
And then Japanese can be displayed too.
So there's no motivation for him to install JP again.
But what if that guy installs JP?
Every common chars will be displayed in JP style on his Latin system.
It annoys him because he's Chinese...
Now comes the issue I want to solve.
I want SC to be used for display even he installed both.
Then I can't use NotoSansCJKSC-hinted.zip as source code.
I need to head to the NotoSansSC.zip as source code.
Because that tarball contains Chinese only. and NotoSansJP.zip
contains Japanese only.
They can be used together now. (I still don't know how common chars display yet)
But NotoSansSC.zip doesn't contain the Noto Sans SC Monospace.
There's no such font, if you want a native monospace, you can only use
Noto Sans CJK SC Monospace,
which is in NotoSansCJKSC-hinted.zip.
NotoSansCJKSC-hinted and NotoSansSC.zip must be used as source code both.
But in the final product, noto-sans-cjksc-fonts contains the Noto Sans
SC and Noto Sans CJK SC Monospace.
Every other stuff will be deleted when packaging.
So it will not affect the RPM size, but we need to host more stuff on
OBS and in the .src.rpm.
But since no one raise that need. I think we don't need to be that complicated.
Just assume no one will install two fonts should be okay.

Hmm, that assumption is very naive, I have to say, sorry.

If people in Latin environment require CJK, they would often need not
only one of CJK but *some multiples* of CJK; i.e. in YaST2 language
setup, both Chinese and Japanese are marked as the supported
languages. Then what happens? The "supported" fonts are installed
automatically, thus both noto-sans-cjksc-* and *-cjkjp-* are
installed ==> Ouch.

And, many CJK-native people rather prefer the correct glyphs in other
languages (and it's sometimes a must), thus multiple fonts are
requirement.

That being said, I still think the fontconfig solution (e.g.
specifying the preferred CJK in the setup) is mandatory no matter how
you do with the fonts.

At the same time, we can think of splitting the fonts. But I don't
think we need to mix up CJK to each variant. If the appearance issue
is fixed by the fontconfig setup, why not SC containing SC only, JP
only JP? It makes things easier, you can convert straightforwardly
from the source zip.

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-11 15:15:26 UTC

Post by Takashi Iwai
No, it's not the only requirement. Often we *need* to have the
correct output from the web page. Imagine if you want to print out
some official web page written in Chinese (to declare at airport or at
embassy) but with *-cjkjp-fonts: would Chinese government official
accept / prefer such a print out? I doubt it.

Haha, passports usually specifies a certain font (SimSun) and it's none
of Noto's business. But the "print" case is still valid.

For reading, you just need to know the meaning, but for printing, you
need it to be exactly what it appears.

And Dr. Weng just pointed out, if you copy something like 门 from web, it'll be
different when you paste it on your local system.

Then it becomes a valid bug actually.

And we _must_ not use the SuperOTC to provide the Noto fonts.

Because that kind of font is designed for profession software like
Adobe InDesign.

Unfortunately fontconfig doesn't support that kind of feature like InDesign.

So it's not a comparison and compromise between the DVD size and the exact look
anymore.

Frederic, I hope you can understand this, it's like you copy "wort"
from your browser,
but the pasted content strangely becomes "word" in your local word
processing software.
and no way you can change it back unless you know German and type it
by yourself.

Takashi, I visit this page: https://ja.wiktionary.org/wiki/%E9%97%A8,
and copy the the word
you see, and it becomes 门 everywhere on my local system.

To resolve this issue, we can only use the region specific font (AKA.
"subset OTF").

That is, forget about the one for all solution.

jp chars belongs to jp font and sc chars belongs to sc font, just like
the old days.

And as they're subsets, the size will be reduced too. (the biggest one
is ~47mb.)

The only problem we still need to solve is: monospace fonts.

Subset OTFs doesn't provide the monospace fonts we used to have.

They're provided by the OTC format.

We can still have them by extracting them from OTC.

But the above problems Takashi pointed out will still remains for monospace:

You installed two variants and everything is displayed in JP glyphs.

But it's better than nothing...it'll not be resolved until fontconfig implements
that feature (OpenType locl GSUB)

Post by Takashi Iwai
The bad thing in this way is that it *apparently* looks OK although
it's incorrect. "Understandable" and "correct" are different.
Just like a difference between "word" in English and "Wort" in
German.

Yes, you're right. Understandable doesn't mean correct.

Post by Takashi Iwai
So, when multiple noto-sans-cjk* fonts are installed, the situation is
still very same as OTC, right? Then it means that we *do* still have
the same bug.
There are tons of situations we need such multiple fonts. That is, we
have to fix it properly in anyway via fontconfig.

Yes.

You can take the previous fontconfig configuration I added as an invalid fix.

Because I didn't take into consideration that non CJK users may want to
display CJK.

I just tweaks for those CJK users who have their locale set correctly.

It didn't cover the case that Latin as main UI language at all.

And as I said in previous section, the SuperOTC is just a mistake.

It's not for fontconfig at all.

So there's no "anyway", we can't tweak for something that fontconfig
didn't implement.

Post by Takashi Iwai
Hmm, that assumption is very naive, I have to say, sorry.
If people in Latin environment require CJK, they would often need not
only one of CJK but *some multiples* of CJK; i.e. in YaST2 language
setup, both Chinese and Japanese are marked as the supported
languages. Then what happens? The "supported" fonts are installed
automatically, thus both noto-sans-cjksc-* and *-cjkjp-* are
installed ==> Ouch.
And, many CJK-native people rather prefer the correct glyphs in other
languages (and it's sometimes a must), thus multiple fonts are
requirement.
That being said, I still think the fontconfig solution (e.g.
specifying the preferred CJK in the setup) is mandatory no matter how
you do with the fonts.

Yes, I was naive untill I saw Dr. Weng's comment.

I took it as an inconvenient thing, which is proved to be a bug :-(

Post by Takashi Iwai
At the same time, we can think of splitting the fonts. But I don't
think we need to mix up CJK to each variant. If the appearance issue
is fixed by the fontconfig setup, why not SC containing SC only, JP
only JP? It makes things easier, you can convert straightforwardly
from the source zip.

SC contains SC only and JP only JP is the best solution.

But the DVD size will not be reduced

To "think globally", the only way to reduce the DVD size is not to
bundle that many weights.

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-11 15:44:18 UTC

On Tue, 11 Apr 2017 17:15:26 +0200,

Yes, it's an infamous problem, and it's rather a "feature" of
unicode :) In theory, each application may put the language marker
forcibly at copying and pasting, but it's not practical.

Post by Marguerite Su
And we _must_ not use the SuperOTC to provide the Noto fonts.
Because that kind of font is designed for profession software like
Adobe InDesign.
Unfortunately fontconfig doesn't support that kind of feature like InDesign.
So it's not a comparison and compromise between the DVD size and the exact look
anymore.
Frederic, I hope you can understand this, it's like you copy "wort"
from your browser,
but the pasted content strangely becomes "word" in your local word
processing software.
and no way you can change it back unless you know German and type it
by yourself.
Takashi, I visit this page: https://ja.wiktionary.org/wiki/%E9%97%A8,
and copy the the word
you see, and it becomes 门 everywhere on my local system.
To resolve this issue, we can only use the region specific font (AKA.
"subset OTF").
That is, forget about the one for all solution.
jp chars belongs to jp font and sc chars belongs to sc font, just like
the old days.
And as they're subsets, the size will be reduced too. (the biggest one
is ~47mb.)
The only problem we still need to solve is: monospace fonts.
Subset OTFs doesn't provide the monospace fonts we used to have.
They're provided by the OTC format.
We can still have them by extracting them from OTC.
You installed two variants and everything is displayed in JP glyphs.
But it's better than nothing...it'll not be resolved until fontconfig implements
that feature (OpenType locl GSUB)

Hrm... I don't know why the similar fontconfig workaround can't work
for monospace fonts. The noto-cjk-sans provides the following family:

% fc-scan --format '%{family}\n' ./NotoSansCJK.ttc
Noto Sans CJK JP,Noto Sans CJK JP Thin
Noto Sans CJK KR,Noto Sans CJK KR Thin
Noto Sans CJK SC,Noto Sans CJK SC Thin
Noto Sans CJK TC,Noto Sans CJK TC Thin
Noto Sans CJK JP,Noto Sans CJK JP Light
Noto Sans CJK KR,Noto Sans CJK KR Light
Noto Sans CJK SC,Noto Sans CJK SC Light
Noto Sans CJK TC,Noto Sans CJK TC Light
Noto Sans CJK JP,Noto Sans CJK JP DemiLight
Noto Sans CJK KR,Noto Sans CJK KR DemiLight
Noto Sans CJK SC,Noto Sans CJK SC DemiLight
Noto Sans CJK TC,Noto Sans CJK TC DemiLight
Noto Sans CJK JP,Noto Sans CJK JP Regular
Noto Sans CJK KR,Noto Sans CJK KR Regular
Noto Sans CJK SC,Noto Sans CJK SC Regular
Noto Sans CJK TC,Noto Sans CJK TC Regular
Noto Sans Mono CJK JP,Noto Sans Mono CJK JP Regular
Noto Sans Mono CJK KR,Noto Sans Mono CJK KR Regular
Noto Sans Mono CJK SC,Noto Sans Mono CJK SC Regular
Noto Sans Mono CJK TC,Noto Sans Mono CJK TC Regular
Noto Sans CJK JP,Noto Sans CJK JP Medium
Noto Sans CJK KR,Noto Sans CJK KR Medium
Noto Sans CJK SC,Noto Sans CJK SC Medium
Noto Sans CJK TC,Noto Sans CJK TC Medium
Noto Sans CJK JP,Noto Sans CJK JP Bold
Noto Sans CJK KR,Noto Sans CJK KR Bold
Noto Sans CJK SC,Noto Sans CJK SC Bold
Noto Sans CJK TC,Noto Sans CJK TC Bold
Noto Sans Mono CJK JP,Noto Sans Mono CJK JP Bold
Noto Sans Mono CJK KR,Noto Sans Mono CJK KR Bold
Noto Sans Mono CJK SC,Noto Sans Mono CJK SC Bold
Noto Sans Mono CJK TC,Noto Sans Mono CJK TC Bold
Noto Sans CJK JP,Noto Sans CJK JP Black
Noto Sans CJK KR,Noto Sans CJK KR Black
Noto Sans CJK SC,Noto Sans CJK SC Black
Noto Sans CJK TC,Noto Sans CJK TC Black

.... and what we need to do is to have a proper preference for each
family definition. Or, what else am I missing?

Basically, the situation with OTC is nothing different from the
situation with multiple OTFs installed. That is, even if you use
OTFs, the problem still exists as long as you may install multiple
such fonts.

Think like this: you have two users on your machine, one Japanese and
one Chinese. What would you do?

With your proposal, they still need to install both cjksc and cjkjp
fonts, although both of them cover the whole CJK glyphs.

Yes, you're right. Understandable doesn't mean correct.

Well, we know that the current fontconfig setup is incomplete. But it
doesn't mean that it's impossible to support by fontconfig.

For non-CJK users, we'd need some explicit listing of the preferred
CJK, e.g. provided in /etc/sysconfig/fonts-config. According to the
given information, fonts-config can set up the preferred noto fonts
listing. If the preferred CJK is empty, the system picks up depending
on the running locale or the first-matching one, etc.

Post by Marguerite Su
And as I said in previous section, the SuperOTC is just a mistake.
It's not for fontconfig at all.
So there's no "anyway", we can't tweak for something that fontconfig
didn't implement.

It's too early to give up the hope. The empire doesn't invade the
whole galaxy yet.

As mentioned, OTC is simply a collection of fonts, and it's nothing
more than the multiple installed OTFs. You can't go away from the
issue until you face to and defeat it seriously.

Yes, I was naive untill I saw Dr. Weng's comment.
I took it as an inconvenient thing, which is proved to be a bug :-(

SC contains SC only and JP only JP is the best solution.
But the DVD size will not be reduced
To "think globally", the only way to reduce the DVD size is not to
bundle that many weights.

Right, at this moment, we should think of two things:

1. Reduction of the files on DVD

This can be achieved at best by splitting per weight. Then each OTF
will be much smaller. Then there shouldn't be a big problem to have a
few OTFs on the DVD.

2. Handling of multiple installed CJK fonts

We need the fontconfig setup with the preferred list that is
dynamically generated per the running locale (for CJK-native) or the
locale specified by user explicitly (for non-CJK).

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Weng Xuetian

2017-04-08 16:04:52 UTC

On Saturday, 8 April 2017 02:09:53 PDT，Takashi Iwai wrote：

Post by Takashi Iwai
On Sat, 08 Apr 2017 10:21:34 +0200,

Post by Marguerite Su
Hi, Takashi,

Well, suppose you install only noto-sans-cjksc-fonts for Simplified
Chinese locale, and visit a Japanese web page. Would it be shown
correctly with Japanese glyphs even for the CJK unified ideographs?
If my understanding is correct, it wouldn't. When you install
noto-sans-cjkja-fonts in addition and choose it explicitly, then you
can show the Japanese glyphs for such letters properly, though.

Sorry, I'm confused by the argument here. I supposed that splitting
to subpackages for each region and weight is for reducing the size as
the primary goal?
We might need to reach to some compromise between the reasonable size
reduction and the easy installation / management, but the above
doesn't look well-explaining to me.
BTW, please keep Frederic in the loop, as he's involved in SLE-Desktop
side.
thanks,
Takashi

Japanese: Loading Image...

Hope you noticed the difference in the image above. But if you try to copy
paste the character from webpage to your desktop app (kwrite for example),
you'll see it "changes" to a certain shape depends on your system
configurtaion.

And how the webpage deals with that? They use lang="ja" in the html tag to
force it to use the Japanese standard, and lang="zh" to force the Chinese
standard.

The problem is, unlike the webpage which allows you force the font usage with
"lang", the font used by your desktop doesn't take "LANG" or "LC_*" into
consideration (problaby you can take that as a bug in fontconfig ? I don't
know).

When OTC is installed (and without any fontconfig configuration), even under the
"zh_XX.UTF-8", it will use the style of second image to display "骨". Not to
mention the character that looks totally different https://en.wiktionary.org/
wiki/%E9%97%A8 . (and sadly they share the same unicode, not possible for
desktop app to distinguish them).

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-09 07:50:54 UTC

On Sat, 08 Apr 2017 18:04:52 +0200,

Post by Weng Xuetian
On Saturday, 8 April 2017 02:09:53 PDT，Takashi Iwai wrote：

Post by Takashi Iwai
On Sat, 08 Apr 2017 10:21:34 +0200,

Post by Marguerite Su
Hi, Takashi,

Well, suppose you install only noto-sans-cjksc-fonts for Simplified
Chinese locale, and visit a Japanese web page. Would it be shown
correctly with Japanese glyphs even for the CJK unified ideographs?
If my understanding is correct, it wouldn't. When you install
noto-sans-cjkja-fonts in addition and choose it explicitly, then you
can show the Japanese glyphs for such letters properly, though.

Sorry, I'm confused by the argument here. I supposed that splitting
to subpackages for each region and weight is for reducing the size as
the primary goal?
We might need to reach to some compromise between the reasonable size
reduction and the easy installation / management, but the above
doesn't look well-explaining to me.
BTW, please keep Frederic in the loop, as he's involved in SLE-Desktop
side.
thanks,
Takashi

Certain characters are shared among CJK in the sense that they have same
unicode.
The problem is, they have same unicode, but differnt countries write them in
the different way. For example, "骨".
(Taken from https://en.wiktionary.org/wiki/%E9%AA%A8)
Chinese: http://i.imgur.com/trR8UTH.png
Japanese: http://i.imgur.com/UgTOdDN.png
Hope you noticed the difference in the image above. But if you try to copy
paste the character from webpage to your desktop app (kwrite for example),
you'll see it "changes" to a certain shape depends on your system
configurtaion.
And how the webpage deals with that? They use lang="ja" in the html tag to
force it to use the Japanese standard, and lang="zh" to force the Chinese
standard.
The problem is, unlike the webpage which allows you force the font usage with
"lang", the font used by your desktop doesn't take "LANG" or "LC_*" into
consideration (problaby you can take that as a bug in fontconfig ? I don't
know).
When OTC is installed (and without any fontconfig configuration), even under the
"zh_XX.UTF-8", it will use the style of second image to display "骨". Not to
mention the character that looks totally different https://en.wiktionary.org/
wiki/%E9%97%A8 . (and sadly they share the same unicode, not possible for
desktop app to distinguish them).

Thanks for details. It's what I meant as "CJK unified ideographs":
https://en.wikipedia.org/wiki/CJK_Unified_Ideographs

I know of the font appearance problem, too, and currently my
suggestion is to keep (or better improve) the fontconfig setup, as you
can't avoid the same problem when you install multiple such fonts, no
matter how you assemble them.

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-10 08:15:48 UTC

On Mon, 10 Apr 2017 10:01:41 +0200,

I find these proposals are sensible and feasible.
As long as the upgrades would work smoothly (and I guess so), I'm for
this movement.

Honestly, I'm not, for the reasons stated above. I'm sorry to be a bit
harsh.

Just a single point here to avoid the misunderstanding:
we're discussing the splitting here not only per language but also per
weight. The latter split will give a lot more reduction.

For normal usages like web browsing, we mostly need a single weight
(or maybe another one for bold) while the current font contains all
multiple weights. We can split them to each package and install only
the essential ones as default. The *-cjk-* meta package also points
only to these essential weights.

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-10 08:43:16 UTC

On Mon, 10 Apr 2017 10:30:18 +0200,

Post by Takashi Iwai
On Mon, 10 Apr 2017 10:01:41 +0200,

Post by Marguerite Su
5 Noto Serif CJK
It'll be easy and don't need that detailed split because it's
not
an
google-noto-serif-cjk{sc|tc|ja|kr}-fonts which contains all
seven
weights.
Of course, font configurations are still needed for Japanese because
the Demi-light issue.

I find these proposals are sensible and feasible.
As long as the upgrades would work smoothly (and I guess so), I'm for
this movement.

Honestly, I'm not, for the reasons stated above. I'm sorry to be a bit
harsh.

we're discussing the splitting here not only per language but also per
weight. The latter split will give a lot more reduction.

Are there numbers for that ?

AFAIK, there are 7 weights (thin, light, demi-light, regular, medium,
bold, black). Also, I forgot to mention about the split of mono and
standard variants, too. Another two counts up.
Fortunately still less than boxing weight classes.

Post by Takashi Iwai
For normal usages like web browsing, we mostly need a single weight
(or maybe another one for bold) while the current font contains all
multiple weights. We can split them to each package and install only
the essential ones as default. The *-cjk-* meta package also points
only to these essential weights.

I'm wondering (coming from Latin world) : is italic used at all on CJK
fonts, or only "regular" and "bold" ?

No, usually no italic for CJK. There can be, but mostly optional.

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-18 09:09:22 UTC

On Mon, 10 Apr 2017 10:43:16 +0200,

Post by Takashi Iwai
On Mon, 10 Apr 2017 10:30:18 +0200,

Post by Takashi Iwai
On Mon, 10 Apr 2017 10:01:41 +0200,

Post by Marguerite Su
5 Noto Serif CJK
It'll be easy and don't need that detailed split because it's
not
an
google-noto-serif-cjk{sc|tc|ja|kr}-fonts which contains all
seven
weights.
Of course, font configurations are still needed for Japanese because
the Demi-light issue.

I find these proposals are sensible and feasible.
As long as the upgrades would work smoothly (and I guess so), I'm for
this movement.

Honestly, I'm not, for the reasons stated above. I'm sorry to be a bit
harsh.

we're discussing the splitting here not only per language but also per
weight. The latter split will give a lot more reduction.

Are there numbers for that ?

For more concrete numbers, take a look at github noto-cjk repo:
https://github.com/googlei18n/noto-cjk

IMO, from the DVD size reduction POV, the best bet is OTC split per
weight. For example, NotoSansCJK-Regular.ttc is 17.9MB containing all
CJK glyphs. Of course, this has the same problem with the package we
have currently, and the fontconfig workaround is still required.

A single split OTF would reduce the installation size if one language
is used. And it would work more easily without fontconfig for a
single locale. But it'll more than double size on DVD than (split-)
OTC when shipping the all CJK in the end, and the fontconfig
workaround is still required when multiple fonts are installed.

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-23 14:36:59 UTC

Hi,

During this weekend, I stripped Noto Sans CJK from google-noto-fonts
and created two new packages:

https://build.opensuse.org/request/show/490020
https://build.opensuse.org/request/show/490022
https://build.opensuse.org/request/show/490023

The later two SRs are google-noto-sans/serif-cjk-fonts.

They are packaged/splitted by region and weight. eg:

noto-sans/serif-sc-regular-font
noto-sans/serif-sc-bold-font

and then re-organized with dummy packages:

noto-sans/serif-sc-fonts-mini (requires regular and bold)
noto-sans/serif-sc-fonts (requires all weights)

I used region specific flavor of noto sans/serif. (sc fonts don't
contain tc/jp/kr glyphs so the size is small)

And I counted the size:

* noto-sans-sc-fonts-mini (11.58mb)
* noto-sans-tc-fonts-mini (7.96mb)
* noto-sans-jp-fonts-mini (6.41mb)
* noto-sans-kr-fonts-mini (5.88mb)
* noto-serif-sc-fonts-mini (15.14mb)
* noto-serif-tc-fonts-mini (8.05mb)
* noto-serif-jp-fonts-mini (8.6mb)
* noto-serif-kr-fonts-mini (8.57mb)

which is 72.19mb DVD space in total (31.83mb for sans and 40.36mb for serif)

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-23 18:32:25 UTC

On Sun, 23 Apr 2017 16:36:59 +0200,

Post by Marguerite Su
Hi,
During this weekend, I stripped Noto Sans CJK from google-noto-fonts
https://build.opensuse.org/request/show/490020
https://build.opensuse.org/request/show/490022
https://build.opensuse.org/request/show/490023
The later two SRs are google-noto-sans/serif-cjk-fonts.
noto-sans/serif-sc-regular-font
noto-sans/serif-sc-bold-font
noto-sans/serif-sc-fonts-mini (requires regular and bold)
noto-sans/serif-sc-fonts (requires all weights)
I used region specific flavor of noto sans/serif. (sc fonts don't
contain tc/jp/kr glyphs so the size is small)
* noto-sans-sc-fonts-mini (11.58mb)
* noto-sans-tc-fonts-mini (7.96mb)
* noto-sans-jp-fonts-mini (6.41mb)
* noto-sans-kr-fonts-mini (5.88mb)
* noto-serif-sc-fonts-mini (15.14mb)
* noto-serif-tc-fonts-mini (8.05mb)
* noto-serif-jp-fonts-mini (8.6mb)
* noto-serif-kr-fonts-mini (8.57mb)
which is 72.19mb DVD space in total (31.83mb for sans and 40.36mb for serif)

Thanks! This looks promising. So we effectively halved the size.

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2017-04-26 14:18:33 UTC

Hi,

Thanks Marguerite!

Here are my quick comments.

1. Package naming
- According to font package naming rule, the prefix is not "-font" but "-fonts"
- "noto-sans-*-mono-fonts" should be "noto-sans-mono-cjk-*" from the naming rule?
- I am wondering if the prefix "-mini" is appropriate for our case.
It is used, for example, in "systemd-mini", as an minimal *alternative* of the package
without "-mini".

2. Meta packages
- I am not sure "noto-sans-cjk-*-fonts-mini" meta packages are really necessary.
- We need noto-sans-cjk-fonts package, which "Requires" all those fonts for upgrading
(even though this requires much disk space)
- The meta packages does not need "%reconfigure_fonts_prereq"

I will try to hack fonts-config on vacation next week.

Fuminobu TAKEYAMA

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-26 15:25:35 UTC

Hi, ftake

Post by Fuminobu TAKEYAMA
1. Package naming
- According to font package naming rule, the prefix is not "-font" but "-fonts"

But it's *really* just one font name with one weight. there's no 's' case in it.

I didn't make the 'noto-sans-sc-fonts' wrong...

Post by Fuminobu TAKEYAMA
- "noto-sans-*-mono-fonts" should be "noto-sans-mono-cjk-*" from the naming rule?

why? because it's stripped from the language specific tarballs and
contains all CJK support?

the old name was 'noto-sans-mono-cjksc-fonts' (but I think it should
be 'noto-mono-cjksc-fonts')

but since I decided to use region specific variants, the 'cjksc' is no
longer a proper name
although it *correctly* reflects the fact that these monospace fonts
cover all CJK locales.

anyway this is open to discuss because they're not installed by default.

they'll be dragged in only if the end users install
'noto-sans-sc-fonts' themselves.

Post by Fuminobu TAKEYAMA
- I am wondering if the prefix "-mini" is appropriate for our case.
It is used, for example, in "systemd-mini", as an minimal *alternative* of the package
without "-mini".

Ha, yes, noto-sans-sc-fonts contains all weights and
noto-sans-sc-fonts-mini contains
regular and bold weights. the later is a minimal alternative of the former.

the later and those two weights can be put into the DVD, leaving everything else
in the remote repository.

Post by Fuminobu TAKEYAMA
2. Meta packages
- I am not sure "noto-sans-cjk-*-fonts-mini" meta packages are really necessary.
- We need noto-sans-cjk-fonts package, which "Requires" all those fonts for upgrading
(even though this requires much disk space)

I stripped the packages just to make sure every locale has it's own
meta package.

There's no space for another mega package (or it can exist but not
exist in DVD so
that a default localized installation will not install all other fonts
for other languages)

BTW now I can be sure that if you install noto-sans-jp-fonts-mini, the
old noto-sans-cjk-fonts
will be uninstalled. But I didn't find a way to update
noto-sans-cjk-fonts and install noto-sans-jp-fonts-mini
automatically accordingly. I wonder can it be called 'smooth update'?

PS: I think I should also make the noto-sans-jp-fonts-mini conflicts
with noto-sans-jp-fonts
because they both have regular and bold weights. the later should
provide the former.

Post by Fuminobu TAKEYAMA
- The meta packages does not need "%reconfigure_fonts_prereq"

Sure.

Post by Fuminobu TAKEYAMA
I will try to hack fonts-config on vacation next week.

I've been working on it here in my fork:
https://github.com/marguerite/fonts-config

1. I modified the 'serif' to use 'Noto Serif SC' instead of 'AR PL
UMing' by default

2. I left the 'Noto Sans CJK SC' there in 59-*.conf

But since we will not use Super OTC or Language Specific variants any more,
these font names will be non-existent actually.

So I prepend/append the 'Noto Sans SC' stuff in 32-google-noto-cjk.conf to fake
a font (although I don't know if my fontconfig grammar is correct, please help).

I didn't use 'alias' because in certain cases users may make those namespaces
available by installing those variant themselves.

The same policy should be applied to serif too.

3. I have a TODO in my fork, you can check that. it's the goal we need to do:

3.1 *colored* emoji support out of the box (50-emoji.conf and a cairo patch)

https://github.com/googlei18n/noto-emoji/issues/36

3.2 modern symbol font (what's the difference between emoji font and
symbol font? are they the same?)

Deepin project have a 'deepin-opensymbol-fonts' which is 6 fonts that
provide 'MT Extra' 'Webdings'
'Wingding' 'Wingding 2' and two other symbol fonts on M$.

So it's a 100% alternative. we don't need to rely on the ancient one
from LibreOffice

3.3 Adobe Source Hans vs. Google Noto CJK.

They're actually the same with minor difference. eg: the weight.
https://qdan.me/list/VLPe5sfsxkFWYMmX

And Source Hans has a 'HW( half weight )' weight available only in its
language specific variants.

So I think we should use fontconfig to provide Adobe Source Hans as we can.

And only package those missing weights.

But I didn't start working on this at all.

3.4 re-evaluate the choicesin 60-family-prefer.conf

For example, we still have Wenquanyi Zen Hei in the preference of
'sans-serif', and those 'Shanghai Song Uni' and 'AR PL'

What are they? are they still installed on openSUSE by default?

our system fontconfig is not a trash...we shouldn't put everything here.

we should just have a working one, no need to prefer so many ancient
things that few knows today.

I think we can have a start by cleaning CJK substitutes.

Because I will not be available from April. 28th to May 1st. (National
Holiday leave).

So please just step in the any of these topics and send pull requests
to openSUSE/fonts-config
when you're ready.

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2017-04-26 16:04:04 UTC

Post by Marguerite Su
But it's *really* just one font name with one weight. there's no 's' case in it.

There are many font packages ending with "-fonts" and containing only one font.

Post by Marguerite Su
why?

just a rule.
https://en.opensuse.org/openSUSE:Packaging_Fonts

Post by Marguerite Su
why? because it's stripped from the language specific tarballs and
contains all CJK support?
the old name was 'noto-sans-mono-cjksc-fonts' (but I think it should
be 'noto-mono-cjksc-fonts')

According to the naming rule above, package names should come from family names.
The family name is "Noto Sans Mono CJK SC" and not "Noto Mono CJK SC".

# we can also say noto-mono-cjksc is project name although a bit strange.

Post by Marguerite Su
the later is a minimal alternative of the former.

That's just a meta package providing a part of them.
So I think we cannot say it is alternative (similar but different one).

If you intend to minimize Noto fonts by removing the old package,
it would be fine.

Post by Marguerite Su
BTW now I can be sure that if you install noto-sans-jp-fonts-mini, the
old noto-sans-cjk-fonts
will be uninstalled. But I didn't find a way to update
noto-sans-cjk-fonts and install noto-sans-jp-fonts-mini
automatically accordingly. I wonder can it be called 'smooth update'?

I don't think so. We will need to ask "manual update" in the release note.
So, usually, we have to provide noto-sans-cjk-fonts that provides the same font set
for the upgrade compatibility issue.

See the previous discussion.

Post by Marguerite Su
PS: I think I should also make the noto-sans-jp-fonts-mini conflicts
with noto-sans-jp-fonts
because they both have regular and bold weights. the later should
provide the former.

Since they are meta package, so it is no problem, I think.

Post by Marguerite Su
Hi, ftake

Post by Fuminobu TAKEYAMA
1. Package naming
- According to font package naming rule, the prefix is not "-font" but "-fonts"

But it's *really* just one font name with one weight. there's no 's' case in it.
I didn't make the 'noto-sans-sc-fonts' wrong...

Post by Fuminobu TAKEYAMA
- "noto-sans-*-mono-fonts" should be "noto-sans-mono-cjk-*" from the naming rule?

why? because it's stripped from the language specific tarballs and
contains all CJK support?
the old name was 'noto-sans-mono-cjksc-fonts' (but I think it should
be 'noto-mono-cjksc-fonts')
but since I decided to use region specific variants, the 'cjksc' is no
longer a proper name
although it *correctly* reflects the fact that these monospace fonts
cover all CJK locales.
anyway this is open to discuss because they're not installed by default.
they'll be dragged in only if the end users install
'noto-sans-sc-fonts' themselves.

Post by Fuminobu TAKEYAMA
- I am wondering if the prefix "-mini" is appropriate for our case.
It is used, for example, in "systemd-mini", as an minimal *alternative* of the package
without "-mini".

Ha, yes, noto-sans-sc-fonts contains all weights and
noto-sans-sc-fonts-mini contains
regular and bold weights. the later is a minimal alternative of the former.
the later and those two weights can be put into the DVD, leaving everything else
in the remote repository.

I stripped the packages just to make sure every locale has it's own
meta package.
There's no space for another mega package (or it can exist but not
exist in DVD so
that a default localized installation will not install all other fonts
for other languages)
BTW now I can be sure that if you install noto-sans-jp-fonts-mini, the
old noto-sans-cjk-fonts
will be uninstalled. But I didn't find a way to update
noto-sans-cjk-fonts and install noto-sans-jp-fonts-mini
automatically accordingly. I wonder can it be called 'smooth update'?
PS: I think I should also make the noto-sans-jp-fonts-mini conflicts
with noto-sans-jp-fonts
because they both have regular and bold weights. the later should
provide the former.

Post by Fuminobu TAKEYAMA
- The meta packages does not need "%reconfigure_fonts_prereq"

Sure.

Post by Fuminobu TAKEYAMA
I will try to hack fonts-config on vacation next week.

https://github.com/marguerite/fonts-config
1. I modified the 'serif' to use 'Noto Serif SC' instead of 'AR PL
UMing' by default
2. I left the 'Noto Sans CJK SC' there in 59-*.conf
But since we will not use Super OTC or Language Specific variants any more,
these font names will be non-existent actually.
So I prepend/append the 'Noto Sans SC' stuff in 32-google-noto-cjk.conf to fake
a font (although I don't know if my fontconfig grammar is correct, please help).
I didn't use 'alias' because in certain cases users may make those namespaces
available by installing those variant themselves.
The same policy should be applied to serif too.
3.1 *colored* emoji support out of the box (50-emoji.conf and a cairo patch)
https://github.com/googlei18n/noto-emoji/issues/36
3.2 modern symbol font (what's the difference between emoji font and
symbol font? are they the same?)
Deepin project have a 'deepin-opensymbol-fonts' which is 6 fonts that
provide 'MT Extra' 'Webdings'
'Wingding' 'Wingding 2' and two other symbol fonts on M$.
So it's a 100% alternative. we don't need to rely on the ancient one
from LibreOffice
3.3 Adobe Source Hans vs. Google Noto CJK.
They're actually the same with minor difference. eg: the weight.
https://qdan.me/list/VLPe5sfsxkFWYMmX
And Source Hans has a 'HW( half weight )' weight available only in its
language specific variants.
So I think we should use fontconfig to provide Adobe Source Hans as we can.
And only package those missing weights.
But I didn't start working on this at all.
3.4 re-evaluate the choicesin 60-family-prefer.conf
For example, we still have Wenquanyi Zen Hei in the preference of
'sans-serif', and those 'Shanghai Song Uni' and 'AR PL'
What are they? are they still installed on openSUSE by default?
our system fontconfig is not a trash...we shouldn't put everything here.
we should just have a working one, no need to prefer so many ancient
things that few knows today.
I think we can have a start by cleaning CJK substitutes.
Because I will not be available from April. 28th to May 1st. (National
Holiday leave).
So please just step in the any of these topics and send pull requests
to openSUSE/fonts-config
when you're ready.
Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-27 08:51:27 UTC

On Wed, 26 Apr 2017 17:25:35 +0200,

Post by Marguerite Su
Hi, ftake

Post by Fuminobu TAKEYAMA
1. Package naming
- According to font package naming rule, the prefix is not "-font" but "-fonts"

But it's *really* just one font name with one weight. there's no 's' case in it.
I didn't make the 'noto-sans-sc-fonts' wrong...

Well, *-fonts is the standard suffix, so let's keep *-fonts suffix
consistently. This will make it easier to filter / search packages.

Post by Fuminobu TAKEYAMA
- "noto-sans-*-mono-fonts" should be "noto-sans-mono-cjk-*" from the naming rule?

why? because it's stripped from the language specific tarballs and
contains all CJK support?
the old name was 'noto-sans-mono-cjksc-fonts' (but I think it should
be 'noto-mono-cjksc-fonts')
but since I decided to use region specific variants, the 'cjksc' is no
longer a proper name
although it *correctly* reflects the fact that these monospace fonts
cover all CJK locales.
anyway this is open to discuss because they're not installed by default.
they'll be dragged in only if the end users install
'noto-sans-sc-fonts' themselves.

The package name is always a matter of taste, so there is no strict
rule, and I don't argue strongly to both. But, in general, the
package name is generated from either the original font name or the
file name. In this case, it's "Noto Sans Mono CJKxx XXX" or
NotoSansMonoCJKxx-XXX.otf, so noto-sans-mono-*-fonts looks fitting
well, indeed.

Of course, this name brings too much confusion, we should rethink a
better alternative name.

Post by Fuminobu TAKEYAMA
- I am wondering if the prefix "-mini" is appropriate for our case.
It is used, for example, in "systemd-mini", as an minimal *alternative* of
the package
without "-mini".

Ha, yes, noto-sans-sc-fonts contains all weights and
noto-sans-sc-fonts-mini contains
regular and bold weights. the later is a minimal alternative of the former.
the later and those two weights can be put into the DVD, leaving everything else
in the remote repository.

I stripped the packages just to make sure every locale has it's own
meta package.
There's no space for another mega package (or it can exist but not
exist in DVD so
that a default localized installation will not install all other fonts
for other languages)
BTW now I can be sure that if you install noto-sans-jp-fonts-mini, the
old noto-sans-cjk-fonts
will be uninstalled. But I didn't find a way to update
noto-sans-cjk-fonts and install noto-sans-jp-fonts-mini
automatically accordingly. I wonder can it be called 'smooth update'?
PS: I think I should also make the noto-sans-jp-fonts-mini conflicts
with noto-sans-jp-fonts
because they both have regular and bold weights. the later should
provide the former.

I've considered about this for a while. From the functional POV, we
should install all (split) noto-sans-cjk* fonts by migration from the
old single noto-san-cjk-fonts.rpm. But it'll bloat as the result.

Another option is to install the minimal cjk noto-san-* packages
(regular and bold) by upgrading noto-sans-cjk-fonts.rpm. We keep
noto-sans-cjk-fonts.rpm but it becomes a meta package requiring only
regular and bold CJK fonts.
For users who really need the full fontset, we may provide another
meta package, e.g. noto-san-cjk-full-fonts or such that drags the all
relevant fonts in addition to the mini noto-san-cjk-fonts, but they'll
need to install manually.

DVD may contain noto-sans-cjk-fonts.rpm, and it'll bring the minimally
needed font sets.

Post by Fuminobu TAKEYAMA
- The meta packages does not need "%reconfigure_fonts_prereq"

Sure.

Post by Fuminobu TAKEYAMA
I will try to hack fonts-config on vacation next week.

I thought the font (family) names don't change after split?
If so, the workaround is still needed when multiple CJK fonts are
installed, I'm afraid.

Post by Marguerite Su
So I prepend/append the 'Noto Sans SC' stuff in 32-google-noto-cjk.conf to fake
a font (although I don't know if my fontconfig grammar is correct, please help).
I didn't use 'alias' because in certain cases users may make those namespaces
available by installing those variant themselves.
The same policy should be applied to serif too.
3.1 *colored* emoji support out of the box (50-emoji.conf and a cairo patch)
https://github.com/googlei18n/noto-emoji/issues/36
3.2 modern symbol font (what's the difference between emoji font and
symbol font? are they the same?)

Conceptually yes. The difference is how they were invented and
introduced to unicode :)

BTW, the SR for the noto emoji font addition has been blocked because
of the current noto-cjk rework. Let's rip if out from
google-noto-fonts quickly, then improve fontconfig stuff.

Post by Marguerite Su
Deepin project have a 'deepin-opensymbol-fonts' which is 6 fonts that
provide 'MT Extra' 'Webdings'
'Wingding' 'Wingding 2' and two other symbol fonts on M$.
So it's a 100% alternative. we don't need to rely on the ancient one
from LibreOffice
3.3 Adobe Source Hans vs. Google Noto CJK.
They're actually the same with minor difference. eg: the weight.
https://qdan.me/list/VLPe5sfsxkFWYMmX
And Source Hans has a 'HW( half weight )' weight available only in its
language specific variants.
So I think we should use fontconfig to provide Adobe Source Hans as we can.
And only package those missing weights.

Sounds like a good idea.

Post by Marguerite Su
But I didn't start working on this at all.

Don't worry, it should be in a lower priority.

Post by Marguerite Su
3.4 re-evaluate the choicesin 60-family-prefer.conf
For example, we still have Wenquanyi Zen Hei in the preference of
'sans-serif', and those 'Shanghai Song Uni' and 'AR PL'
What are they? are they still installed on openSUSE by default?

I don't think so. It was some commercial fonts which was installed as
default on SLE10 or such.

Post by Marguerite Su
our system fontconfig is not a trash...we shouldn't put everything here.
we should just have a working one, no need to prefer so many ancient
things that few knows today.
I think we can have a start by cleaning CJK substitutes.

Agreed, we need a cleanup work in a lot of places.

Post by Marguerite Su
Because I will not be available from April. 28th to May 1st. (National
Holiday leave).
So please just step in the any of these topics and send pull requests
to openSUSE/fonts-config
when you're ready.

Have a nice vacation. Hopefully we can finish something before your
vacation, though :)

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-27 15:58:41 UTC

Hi,

Post by Takashi Iwai
Well, *-fonts is the standard suffix, so let's keep *-fonts suffix
consistently. This will make it easier to filter / search packages.

Okay, I just created a new SR.

Post by Takashi Iwai
The package name is always a matter of taste, so there is no strict
rule, and I don't argue strongly to both. But, in general, the
package name is generated from either the original font name or the
file name. In this case, it's "Noto Sans Mono CJKxx XXX" or
NotoSansMonoCJKxx-XXX.otf, so noto-sans-mono-*-fonts looks fitting
well, indeed.
Of course, this name brings too much confusion, we should rethink a
better alternative name.

I didn't change this for now. so the current name is still
'noto-sans-sc-mono-fonts

Post by Takashi Iwai
Another option is to install the minimal cjk noto-san-* packages
(regular and bold) by upgrading noto-sans-cjk-fonts.rpm. We keep
noto-sans-cjk-fonts.rpm but it becomes a meta package requiring only
regular and bold CJK fonts.
For users who really need the full fontset, we may provide another
meta package, e.g. noto-san-cjk-full-fonts or such that drags the all
relevant fonts in addition to the mini noto-san-cjk-fonts, but they'll
need to install manually.

I changed like this:

* noto-sans-sc-fonts-mini -> noto-sans-sc-fonts
* noto-sans-sc-fonts -> noto-sans-sc-fonts-extra

the new 'noto-sans-sc/tc/jp/kr-fonts' contains only regular and bold weights.

the new extra contains all other weights except for regular and bold.

and a new 'noto-sans-cjk-fonts' requires all four noto-sans-sc/tc/jp/kr-fonts.

The '-extra' stuff is open to discuss. I didn't make it a '-full' with
regular and bold included because:

1. if so, the '-full' should provide things like 'noto-sans-sc-fonts'
which is exactly the new name of the
old '-mini' package to avoid the file path conflict.

then there'll be two packages provides the same functionality.

and there'll be choices that need to be handled manually by the users.

2. or if the '-full' set to be conflicted with 'noto-sans-sc-fonts'

If users install '-full', then all the meta packages will be uninstalled.

Post by Fuminobu TAKEYAMA
I will try to hack fonts-config on vacation next week.

I thought the font (family) names don't change after split?
If so, the workaround is still needed when multiple CJK fonts are
installed, I'm afraid.

The font family changed actually.

Before: (Super OTC)

The font families are 'Noto Sans CJK SC'.

Now:

The font families are 'Noto Sans SC'

That's why I said 'Noto Sans CJK SC' now doesn't exist on our system,
it's a dummy font.

Then I used 'Noto Sans SC/TC/JP/KR' combination to fake it, see:

https://github.com/marguerite/fonts-config/blob/master/32-google-noto-cjk.conf

So:

1. If users install Super OTC themselves, that font family is
available and will be used.
of course the problems are still the same as before, but they choose
to bear with it.

2. If users use our packages.

2.1 on a localized system, he'll get the right order.

2.2 on a Latin system with all the fonts installed. He'll get the
order in 60-family-prefer.conf.

If he didn't want Japanese glyths he can just uninstall
noto-sans-jp-fonts or change the
order by himself.

compared with the situation before, he can at least get what he wants
to see by uninstalling
package he doesn't need.

Post by Marguerite Su
3.2 modern symbol font (what's the difference between emoji font and
symbol font? are they the same?)

Conceptually yes. The difference is how they were invented and
introduced to unicode :)

So?

I took a look at the fontconfig configuration to correctly display
emoji on the screen,
it looks like the emoji fonts were treated as the 1st choice for 'sans-serif'.

Do we still need to append these emoji fonts to 'symbol'?

Post by Takashi Iwai
BTW, the SR for the noto emoji font addition has been blocked because
of the current noto-cjk rework. Let's rip if out from
google-noto-fonts quickly, then improve fontconfig stuff.

Yes, I see and I agree.

The google-noto-fonts SR can be accepted first to make a way for the
following SRs

It doesn't nothing but remove CJK.

Post by Takashi Iwai
Sounds like a good idea.

Yes. but I still don't know how to use a certain weight of a font to provide
another weight of another font, eg:

Adobe Source Han Sans Light (200 weight) == Google Noto Sans CJK Light
(300 weight)

So how to do the math to make a 200 weight Noto Sans CJK Light to
provide the former?

Is there any 'scale' function for fontconfig?

I don't think so. It was some commercial fonts which was installed as
default on SLE10 or such.

I see. but are you sure there're still people using SLED 10?

Because the SLES just have TTYs which doesn't support CJK at all.

So at least the ancient open source CJK fonts can be cleaned up.

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-27 16:12:03 UTC

On Thu, 27 Apr 2017 17:58:41 +0200,

* noto-sans-sc-fonts-mini -> noto-sans-sc-fonts
* noto-sans-sc-fonts -> noto-sans-sc-fonts-extra
the new 'noto-sans-sc/tc/jp/kr-fonts' contains only regular and bold weights.
the new extra contains all other weights except for regular and bold.
and a new 'noto-sans-cjk-fonts' requires all four noto-sans-sc/tc/jp/kr-fonts.
The '-extra' stuff is open to discuss. I didn't make it a '-full' with
1. if so, the '-full' should provide things like 'noto-sans-sc-fonts'
which is exactly the new name of the
old '-mini' package to avoid the file path conflict.
then there'll be two packages provides the same functionality.
and there'll be choices that need to be handled manually by the users.

How about using the package dependency? That is,

- noto-sans-cjk-fonts: containing only regular and bold

- noto-sans-cjk-extra/full-fonts: containing the rest of weights, and
it has "Requires: noto-sans-cjk-fonts" tag so that it fetches the
full set.

Post by Marguerite Su
2. or if the '-full' set to be conflicted with 'noto-sans-sc-fonts'
If users install '-full', then all the meta packages will be uninstalled.

Post by Fuminobu TAKEYAMA
I will try to hack fonts-config on vacation next week.

I thought the font (family) names don't change after split?
If so, the workaround is still needed when multiple CJK fonts are
installed, I'm afraid.

The font family changed actually.
Before: (Super OTC)
The font families are 'Noto Sans CJK SC'.
The font families are 'Noto Sans SC'

Aha, interesting. When I took a look at the individual *.otf file in
the past, it still showed Noto Sans CJK XX. Maybe it was changed
since then?

Post by Marguerite Su
That's why I said 'Noto Sans CJK SC' now doesn't exist on our system,
it's a dummy font.
https://github.com/marguerite/fonts-config/blob/master/32-google-noto-cjk.conf
1. If users install Super OTC themselves, that font family is
available and will be used.
of course the problems are still the same as before, but they choose
to bear with it.

Well, the "Noto Sans CJK XX" will still appear when user installs OTC
or the old OTF independently, so it's not too bad to keep it. It's
harmless for now, unless such a font is installed, right?

Post by Marguerite Su
2. If users use our packages.
2.1 on a localized system, he'll get the right order.
2.2 on a Latin system with all the fonts installed. He'll get the
order in 60-family-prefer.conf.
If he didn't want Japanese glyths he can just uninstall
noto-sans-jp-fonts or change the
order by himself.
compared with the situation before, he can at least get what he wants
to see by uninstalling
package he doesn't need.

Post by Marguerite Su
3.2 modern symbol font (what's the difference between emoji font and
symbol font? are they the same?)

Conceptually yes. The difference is how they were invented and
introduced to unicode :)

So?
I took a look at the fontconfig configuration to correctly display
emoji on the screen,
it looks like the emoji fonts were treated as the 1st choice for 'sans-serif'.
Do we still need to append these emoji fonts to 'symbol'?

Heck, I have also little idea about the fontconfig hack for emoji,
too, so far...

Yes, I see and I agree.
The google-noto-fonts SR can be accepted first to make a way for the
following SRs
It doesn't nothing but remove CJK.

OK, let's start with that.

But maybe it's safer to keep it in M17N:fonts until the rest is worked
out. Then we can submit all to FACTORY at once. (The only important
thing is not to forget the procedure :)

Post by Takashi Iwai
Sounds like a good idea.

Yes. but I still don't know how to use a certain weight of a font to provide
Adobe Source Han Sans Light (200 weight) == Google Noto Sans CJK Light
(300 weight)
So how to do the math to make a 200 weight Noto Sans CJK Light to
provide the former?
Is there any 'scale' function for fontconfig?

I guess no such support, and possibly we'll have to write up the
matching manually by hands...

I don't think so. It was some commercial fonts which was installed as
default on SLE10 or such.

I see. but are you sure there're still people using SLED 10?

Maybe not, but the fonts may be still present.

Post by Marguerite Su
Because the SLES just have TTYs which doesn't support CJK at all.

Hm? SLES is with GNOME desktop, even as default.

Post by Marguerite Su
So at least the ancient open source CJK fonts can be cleaned up.

Yes, I have no objection for the cleanup, just explained where it came
from. Please go head.

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-27 16:36:43 UTC

Post by Takashi Iwai
How about using the package dependency? That is,
- noto-sans-cjk-fonts: containing only regular and bold
- noto-sans-cjk-extra/full-fonts: containing the rest of weights, and
it has "Requires: noto-sans-cjk-fonts" tag so that it fetches the
full set.

I was stupid. will do that :-)

Post by Takashi Iwai
Aha, interesting. When I took a look at the individual *.otf file in
the past, it still showed Noto Sans CJK XX. Maybe it was changed
since then?

Or maybe you looked at the language specific one?

in Super OTC and language specific variants, the font family names are with CJK.

in Region specific variant, the font family names are without CJK

Post by Takashi Iwai
Well, the "Noto Sans CJK XX" will still appear when user installs OTC
or the old OTF independently, so it's not too bad to keep it. It's
harmless for now, unless such a font is installed, right?

Yes. But user installs such a font by themselves, it's not our fault any more.

I think the only way to get rid of this problem is to forbid the usage
of 'CJK' variant.

That is, even if user installs such a font, we still use our fake.

But that'll be bad if he also uninstalls our font packages because no
way he can display
with his own installation.

Post by Takashi Iwai
Heck, I have also little idea about the fontconfig hack for emoji,
too, so far...

Glad to hear that.

All current online implementation are based on one 'fact':

The emoji font used should contain any other 'symbol's that're not emoji.

Or such symbols provided by the sans-serif font used to display normal texts
will be overrided.

But since I am not a heavy emoji user, I know neither 'what other symbols that
are not emoji are' nor 'how to see if an emoji font covers other symbols'.

Post by Takashi Iwai
OK, let's start with that.
But maybe it's safer to keep it in M17N:fonts until the rest is worked
out. Then we can submit all to FACTORY at once. (The only important
thing is not to forget the procedure :)

Sure

Post by Takashi Iwai
Sounds like a good idea.

I guess no such support, and possibly we'll have to write up the
matching manually by hands...

Fontconfig 'matrix' can be used to tweak the look of a font.

So we can use 'matrix' to scale Noto Sans CJK Light down to 2/3 to look like
Adobe Source Han Sans Light?

I don't think so. It was some commercial fonts which was installed as
default on SLE10 or such.

I see. but are you sure there're still people using SLED 10?

Maybe not, but the fonts may be still present.

We'll not drop the fonts from repo, but drop them from using in fontconfig.

Post by Marguerite Su
Because the SLES just have TTYs which doesn't support CJK at all.

Hm? SLES is with GNOME desktop, even as default.

Err...does the last 'S' in SLES mean 'Server'?

GNOME desktop should be SLED, I think...

Post by Marguerite Su
So at least the ancient open source CJK fonts can be cleaned up.

Yes, I have no objection for the cleanup, just explained where it came
from. Please go head.

Thanks, but as said, it's low priority for now.

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2017-04-28 03:57:31 UTC

Post by Marguerite Su
Or maybe you looked at the language specific one?
in Super OTC and language specific variants, the font family names are with CJK.
in Region specific variant, the font family names are without CJK

I now understand your new package containing region-specific OTF not multilingual OTF.
https://github.com/googlei18n/noto-cjk

Some of my comments come from my misunderstanding...

Difference of family name means those fonts are not the same. So one idea I have now
is how about and what happens if providing both region specific and Super OTC.

Super OTC is for compatibility and those who want to use special OTC features.
Of course, Super OTC is not pushed into DVD due to the disk space.

Noto Sans fonts are really complicated...

Thanks,
Fuminobu TAKEYAMA

I was stupid. will do that :-)

Post by Takashi Iwai
Aha, interesting. When I took a look at the individual *.otf file in
the past, it still showed Noto Sans CJK XX. Maybe it was changed
since then?

Or maybe you looked at the language specific one?
in Super OTC and language specific variants, the font family names are with CJK.
in Region specific variant, the font family names are without CJK

Yes. But user installs such a font by themselves, it's not our fault any more.
I think the only way to get rid of this problem is to forbid the usage
of 'CJK' variant.
That is, even if user installs such a font, we still use our fake.
But that'll be bad if he also uninstalls our font packages because no
way he can display
with his own installation.

Post by Takashi Iwai
Heck, I have also little idea about the fontconfig hack for emoji,
too, so far...

Glad to hear that.
The emoji font used should contain any other 'symbol's that're not emoji.
Or such symbols provided by the sans-serif font used to display normal texts
will be overrided.
But since I am not a heavy emoji user, I know neither 'what other symbols that
are not emoji are' nor 'how to see if an emoji font covers other symbols'.

Sure

Post by Takashi Iwai
Sounds like a good idea.

I guess no such support, and possibly we'll have to write up the
matching manually by hands...

Fontconfig 'matrix' can be used to tweak the look of a font.
So we can use 'matrix' to scale Noto Sans CJK Light down to 2/3 to look like
Adobe Source Han Sans Light?

I don't think so. It was some commercial fonts which was installed as
default on SLE10 or such.

I see. but are you sure there're still people using SLED 10?

Maybe not, but the fonts may be still present.

We'll not drop the fonts from repo, but drop them from using in fontconfig.

Post by Marguerite Su
Because the SLES just have TTYs which doesn't support CJK at all.

Hm? SLES is with GNOME desktop, even as default.

Err...does the last 'S' in SLES mean 'Server'?
GNOME desktop should be SLED, I think...

Post by Marguerite Su
So at least the ancient open source CJK fonts can be cleaned up.

Yes, I have no objection for the cleanup, just explained where it came
from. Please go head.

Thanks, but as said, it's low priority for now.
Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-04-28 11:56:59 UTC

JFYI,

I accepted these two SR's, and now google-noto-sans-cjk-fonts and
google-noto-serif-cjk-fonts landed to M17N:fonts project, as well as
the drop of noto-*-cjk from google-noto-fonts.

I'm not sure whether noto-sans-*-fonts-full package name is the right
thing. Or better named to be noto-sans-*-full-fonts? I don't mind
either cases, so I'd like to hear others' opinions.

Now the most important task is to check whether the upgrade
expectedly. Once when confirmed to work, let's feed to FACTORY.

thanks,

Takashi

On Thu, 27 Apr 2017 18:36:43 +0200,

I was stupid. will do that :-)

Post by Takashi Iwai
Aha, interesting. When I took a look at the individual *.otf file in
the past, it still showed Noto Sans CJK XX. Maybe it was changed
since then?

Or maybe you looked at the language specific one?
in Super OTC and language specific variants, the font family names are with CJK.
in Region specific variant, the font family names are without CJK

Yes. But user installs such a font by themselves, it's not our fault any more.
I think the only way to get rid of this problem is to forbid the usage
of 'CJK' variant.
That is, even if user installs such a font, we still use our fake.
But that'll be bad if he also uninstalls our font packages because no
way he can display
with his own installation.

Post by Takashi Iwai
Heck, I have also little idea about the fontconfig hack for emoji,
too, so far...

Sure

Post by Takashi Iwai
Sounds like a good idea.

I guess no such support, and possibly we'll have to write up the
matching manually by hands...

Fontconfig 'matrix' can be used to tweak the look of a font.
So we can use 'matrix' to scale Noto Sans CJK Light down to 2/3 to look like
Adobe Source Han Sans Light?

I don't think so. It was some commercial fonts which was installed as
default on SLE10 or such.

I see. but are you sure there're still people using SLED 10?

Maybe not, but the fonts may be still present.

We'll not drop the fonts from repo, but drop them from using in fontconfig.

Post by Marguerite Su
Because the SLES just have TTYs which doesn't support CJK at all.

Hm? SLES is with GNOME desktop, even as default.

Err...does the last 'S' in SLES mean 'Server'?
GNOME desktop should be SLED, I think...

Post by Marguerite Su
So at least the ancient open source CJK fonts can be cleaned up.

Yes, I have no objection for the cleanup, just explained where it came
from. Please go head.

Thanks, but as said, it's low priority for now.
Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-05-04 13:32:01 UTC

On Fri, 28 Apr 2017 13:56:59 +0200,

Post by Takashi Iwai
JFYI,
I accepted these two SR's, and now google-noto-sans-cjk-fonts and
google-noto-serif-cjk-fonts landed to M17N:fonts project, as well as
the drop of noto-*-cjk from google-noto-fonts.
I'm not sure whether noto-sans-*-fonts-full package name is the right
thing. Or better named to be noto-sans-*-full-fonts? I don't mind
either cases, so I'd like to hear others' opinions.
Now the most important task is to check whether the upgrade
expectedly. Once when confirmed to work, let's feed to FACTORY.

I tested the upgrade and it seems working. So, basically we're ready
to submit to FACTORY.

As said, one remaining question is the naming of the full fontset.
Which is better: noto-sans-xx-fonts-full or noto-sans-xx-full-fonts?

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2017-05-05 12:03:14 UTC

Post by Takashi Iwai
As said, one remaining question is the naming of the full fontset.
Which is better: noto-sans-xx-fonts-full or noto-sans-xx-full-fonts?

I prefer noto-sans-xx-fonts-full because the latter one looks a package
whose family name is "Noto Sanx XX Full".

--
Fuminobu TAKEYAMA

Post by Takashi Iwai
On Fri, 28 Apr 2017 13:56:59 +0200,

I tested the upgrade and it seems working. So, basically we're ready
to submit to FACTORY.
As said, one remaining question is the naming of the full fontset.
Which is better: noto-sans-xx-fonts-full or noto-sans-xx-full-fonts?
thanks,
Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2017-05-09 19:40:27 UTC

On Fri, 05 May 2017 14:03:14 +0200,

Post by Takashi Iwai
As said, one remaining question is the naming of the full fontset.
Which is better: noto-sans-xx-fonts-full or noto-sans-xx-full-fonts?

I prefer noto-sans-xx-fonts-full because the latter one looks a package
whose family name is "Noto Sanx XX Full".

OK, score 2:0, a clear win. I submitted the current
google-noto-*-cjk-fonts packages as is to FACTORY.

Let's cross fingers.

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2017-05-10 12:33:20 UTC

We still need to submit fonts-config to Factory together.
Otherwise, "Sans" alias will be broken in Chinese Tumbleweed.

Here is a simple fix for that.
https://github.com/openSUSE/fonts-config/pull/1

Thanks,
Fuminobu TAKEYAMA (ftake)

Post by Takashi Iwai
On Fri, 05 May 2017 14:03:14 +0200,

Post by Takashi Iwai
As said, one remaining question is the naming of the full fontset.
Which is better: noto-sans-xx-fonts-full or noto-sans-xx-full-fonts?

I prefer noto-sans-xx-fonts-full because the latter one looks a package
whose family name is "Noto Sanx XX Full".

OK, score 2:0, a clear win. I submitted the current
google-noto-*-cjk-fonts packages as is to FACTORY.
Let's cross fingers.
thanks,
Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-11 15:23:03 UTC

Post by Takashi Iwai
we're discussing the splitting here not only per language but also per
weight. The latter split will give a lot more reduction.

Are there numbers for that ?

I'm working in a draft project, will tell the exact MB numbers when I finished.

But I think it'll be impressing.

I'm wondering (coming from Latin world) : is italic used at all on CJK
fonts, or only "regular" and "bold" ?

Yes, usually we just need the regular weight...

thin, light, demi-light, medium, black actually are useless if you're
just a normal CJK user.

historically, we don't even have italic and bold. we control the font
with "size" only.

italic and bold were introduced for web. but only bold is frequently
used due to the historical reasons.

CJK natively doesn't have italic at all.

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2017-04-08 08:18:40 UTC

Hi,

Post by Marguerite Su
2. the attempt to make it default for CJK.

(snip)

Post by Marguerite Su
And the only concern for this attempt is: Japanese needs its
Demi-light instead of Regular/Medium weight. I think this can be
handled with fontconfig.

Who did say so? It's first time to hear this.

Other concerns are, as I said before,
- The line height of Noto Sans CJK is too big, some applications does not
fit with 800 px screen.
- Japanese are familiar with proportional Hiragana, Katakana glyphs but
Noto CJK does not provide them. On the other hand, since mac and Android
now use monospace Hiragana and Katakana, Noto Sans might be acceptable.

Post by Marguerite Su
4. the symbol part.

See also:
https://bugzilla.suse.com/show_bug.cgi?id=1027872

Best regards,
Fuminobu TAKEYAMA

Post by Marguerite Su
Hi,
There were some discussions about Noto CJK fonts in the ML and in the
comments of an SR: SR#446888
1. the size limit of the DVD.
Due to the size limit, someone chose the SuperOTC format to distribute Noto CJK.
Japanese glyphs will be always preferred because of its alphabetical order.
This was partially resolved using a specific fontconfig configuration,
which prepends the right order by lang. but this solution didn't take
into consideration for cases like "how to display CJK chars right in a
Latin environment".
We wanted to switch back to the OTF fonts, because it's the only way
to solve all related issues.
But we still didn't have a conclusion for the new font names. eg
google-noto-sans-cjksc-thin-font, google-noto-sans-cjk-thin-fonts,
google-noto-sans-cjk-basic-fonts...
Because we want to split the seldom used weights to save space for the DVD.
2. the attempt to make it default for CJK.
I think this need is growing today because Google released Noto Serif
and gave us the possibility to
replace the ancient "AR PL UMing" fonts
And the only concern for this attempt is: Japanese needs its
Demi-light instead of Regular/Medium weight. I think this can be
handled with fontconfig.
3. the conflicts between Adobe Source Han and Noto CJK
I received a bug report and I knew our packagers also prepared partial
support for CJK (TW and JP) from Source Han side.
This is duplicated actually. Because Google and Adobe actually used
the same source.
The only differences are the name and the Latin part.
Adobe used Source Sans for the Latin part, Google inhibited it (So
the two fonts are identical) but wrote a guideline to ask users to
override the Latin part with Noto Sans/Reboto.
So a new need is triggered. We need to write a new fontconfig to alias
Adobe Source Han by Noto CJK and handle the minor weight differences.
4. the symbol part.
openSUSE still used the old URW "Standard Symbol L" or "OpenSymbol"
from libreOffice to provide symbols.
* Noto provides "Noto Emoji"
* "EmojiOne Color"
* Deepin Linux also released a free symbol font "Deepin OpenSymbol"
which is 100% compatible with Wingdings on Windows
I think it's time to evaluate our choice for symbol fonts again.
#################################################
1. I removed CJK support from google-noto-fonts.
Because we really need a new namespace for CJK.
The scalable value and Provides needed to be handled separately and we
don't want to mess the generate-specfile.sh any more.
2. We need to introduce 4 sources (115mb each) to have the monospace font.
The region specific fonts are small (because each only covers one
region eg Japanese, which means you can't display any Chinese), but
they don't provide monospace fonts.
3. We need a new namespace for Noto Serif CJK.
Because it is new and shouldn't have those Provides/Obsoletes.
4. We need to have new names.
google-noto-(sans|serif)-cjk(sc|tc|ja|kr)-{weight}-font
google-noto-(sans|serif)-cjk(sc|tc|ja|kr)-(mini|full)
to group them again..
And our DVD will include google-noto-sans-cjk(sc|tc|ja|kr)-mini only.
which is about 35mb x 4 = 140mb.
google-noto-sans-cjk
which requires google-noto-sans-cjksc-mini or google-noto-sans-cjkja-mini only.
4.1 Latin people don't care the glyph difference between Chinese and
Japanese that much
4.2 each of the four mini package contains full coverage of CJK, so
you will not want to install
another one if you have one.
5 Noto Serif CJK
It'll be easy and don't need that detailed split because it's not an
google-noto-serif-cjk{sc|tc|ja|kr}-fonts which contains all seven weights.
Of course, font configurations are still needed for Japanese because
the Demi-light issue.
Thanks
Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-08 08:30:26 UTC

Hi, Fuminobu,

Post by Fuminobu TAKEYAMA
Who did say so? It's first time to hear this.

I read the previous mailing list posts...I thought I saw you said:

The regular is too bold for display for Japanese, and you want Demi-Light as
the default UI font. If so, it needs fontconfig tweaks because by
default fontconfig
may choose Regular...

Post by Fuminobu TAKEYAMA
Other concerns are, as I said before,
- The line height of Noto Sans CJK is too big, some applications does not
fit with 800 px screen.

Well...I don't know if we can detect screen resolution in fontconfig...but maybe
small screen "definitely" has smaller DPI or something we can take advantage of?

Post by Fuminobu TAKEYAMA
- Japanese are familiar with proportional Hiragana, Katakana glyphs but
Noto CJK does not provide them. On the other hand, since mac and Android
now use monospace Hiragana and Katakana, Noto Sans might be acceptable.

Well...I really don't know about the difference of proportional and monospace...
but there's monospace for Noto CJK JP...can you give me some links so that I
can catch up?

Post by Marguerite Su
4. the symbol part.

https://bugzilla.suse.com/show_bug.cgi?id=1027872

Yes...I read that before. It's really the time for us to support
emoji/colored symbol by default.

But first I need to ping darix hard to set up an upstream
github.com/openSUSE/fonts-config for us.

For years...we just modify the source tarball of fonts-config package
to include new tweaks.

That's not good.

Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2017-04-09 10:09:45 UTC

Post by Marguerite Su
The regular is too bold for display for Japanese, and you want Demi-Light as
the default UI font. If so, it needs fontconfig tweaks because by
default fontconfig
may choose Regular...

Not by me but I guess it is related to the problem that by querying
"Noto Sans CJK JP Regular", fontconfig answers "Noto Sans CJK Medium",
which causes the Regular looks too bold. This problem has been already fixed.

As far as I tested, the Regular weight is fine on normal (96 DPI) display.

Post by Marguerite Su
Well...I don't know if we can detect screen resolution in fontconfig...but maybe
small screen "definitely" has smaller DPI or something we can take advantage of?

This problem is difficult to resolve by fontconfig tweak.
Tweaks in applications will be necessary.

Post by Marguerite Su
Well...I really don't know about the difference of proportional and monospace...
but there's monospace for Noto CJK JP...can you give me some links so that I
can catch up?

http://mix-mplus-ipa.osdn.jp/migu/feature_kana_proportional.svg

A picture from discussion in M+ and Migu fonts. The font above provides
proportional Hiragana and Katakana glyphs (like the current default IPA PGothic)
and the other one provides monospaced ones (like Noto Sans CJK).

Fuminobu TAKEYAMA

Post by Marguerite Su
Hi, Fuminobu,

Post by Fuminobu TAKEYAMA
Who did say so? It's first time to hear this.

The regular is too bold for display for Japanese, and you want Demi-Light as
the default UI font. If so, it needs fontconfig tweaks because by
default fontconfig
may choose Regular...

Post by Fuminobu TAKEYAMA
Other concerns are, as I said before,
- The line height of Noto Sans CJK is too big, some applications does not
fit with 800 px screen.

Well...I don't know if we can detect screen resolution in fontconfig...but maybe
small screen "definitely" has smaller DPI or something we can take advantage of?

Well...I really don't know about the difference of proportional and monospace...
but there's monospace for Noto CJK JP...can you give me some links so that I
can catch up?

Post by Marguerite Su
4. the symbol part.

https://bugzilla.suse.com/show_bug.cgi?id=1027872

Yes...I read that before. It's really the time for us to support
emoji/colored symbol by default.
But first I need to ping darix hard to set up an upstream
github.com/openSUSE/fonts-config for us.
For years...we just modify the source tarball of fonts-config package
to include new tweaks.
That's not good.
Marguerite

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Stefan Knorr

2017-04-11 10:53:50 UTC

Hi.

Post by Marguerite Su
But first I need to ping darix hard to set up an upstream
github.com/openSUSE/fonts-config for us.

After reading your mail, we just created that repo for you and
gave the M17N team (= you) write permission.

hth.

Stefan.

--- .
SUSE Linux GmbH. Geschäftsführer: Felix Imendörffer, Jane Smithard,
Graham Norton. HRB 21284 (AG Nürnberg).

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2017-04-11 15:27:49 UTC