On Sat, 08 Apr 2017 08:54:29 +0200, Marguerite Su wrote:

Hi,

There were some discussions about Noto CJK fonts in the ML and in the comments of an SR: SR#446888

I want to summarize the concerns from different sides here:

1. the size limit of the DVD.

Due to the size limit, someone chose the SuperOTC format to distribute Noto CJK.

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

And it brought some troubles like:

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.

But there're a few new modern and even colored symbol fonts available now:

* 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.

#################################################

I'll address 3 and 4 in fonts-config package. for 1 and 2:

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.

I want to write a new script to name the fonts to:

google-noto-(sans|serif)-cjk(sc|tc|ja|kr)-{weight}-font

That is, fully separate them first, and then use dummy packages:

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.

and there'll be a new dummy package:

google-noto-sans-cjk

which requires google-noto-sans-cjksc-mini or google-noto-sans-cjkja-mini only.

because:

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.

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.

5 Noto Serif CJK

It'll be easy and don't need that detailed split because it's not an UI font....it'll be just named:

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

Hi, Takashi, On Sat, Apr 8, 2017 at 3:50 PM, Takashi Iwai wrote:

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 :-)

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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

Hi, Takashi,

On Sat, Apr 8, 2017 at 3:50 PM, Takashi Iwai wrote:

...

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?

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.

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 :-)

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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

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

Marguerite Su wrote:

...

Hi, Takashi,

On Sat, Apr 8, 2017 at 3:50 PM, Takashi Iwai wrote:

...

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?

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.

...

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 :-)

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). -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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

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

...

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

Marguerite Su wrote:

...

Hi, Takashi,

On Sat, Apr 8, 2017 at 3:50 PM, Takashi Iwai wrote:

...

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?

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.

...

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 :-)

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

Le samedi 08 avril 2017 à 09:50 +0200, Takashi Iwai a écrit :

On Sat, 08 Apr 2017 08:54:29 +0200, Marguerite Su wrote:

...

Hi,

There were some discussions about Noto CJK fonts in the ML and in the comments of an SR: SR#446888

I want to summarize the concerns from different sides here:

1. the size limit of the DVD.

Due to the size limit, someone chose the SuperOTC format to distribute Noto CJK.

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

And I still think we should continue this path.

...

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" :)

No, this is false. We just got a bug report on SLED 12 SP3 beta because we weren't shipping any CJK font by default, causing asian web pages to not be properly displayed on a "latin" environment. So, now, we install noto-cjk: yes, the big package will all fonts in a single set because we don't known in advance which language will be displayed and we don't want to loose disk space on this The issue is we keep getting "per language" hacks, because people in each language tend to focus on "their" language, without keeping the "big picture" at view. Having a single font package just put the issue much more visible than splitting fonts per package (so, you don't see the issue until two packages are installed..

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, I fully agree with this assessment.

...

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.

And we are going to end-up with more disk space used for most "latin" people and still no fix in that case, since there won't be any fontconfig "fix" for ti.

...

5 Noto Serif CJK

It'll be easy and don't need that detailed split because it's not an UI font....it'll be just named:

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. -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

Le lundi 10 avril 2017 à 10:15 +0200, Takashi Iwai a écrit :

On Mon, 10 Apr 2017 10:01:41 +0200, Frederic Crozat wrote:

...

...

...

5 Noto Serif CJK

It'll be easy and don't need that detailed split because it's not an UI font....it'll be just named:

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.

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.

Are there numbers for that ? 

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" ?  -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

Hi.

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

...

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.

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.

...

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" ?

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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

On Sun, Apr 9, 2017 at 3:47 PM, Takashi Iwai wrot

...

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.

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.

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)

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.

...

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.

...

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.

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.

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.

...

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 :-(

...

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.

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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 On 2017/04/23 23:36, Marguerite Su wrote:

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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.

why?

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

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.

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.

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.

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. On 2017/04/27 0:25, Marguerite Su wrote:

Hi, ftake

On Wed, Apr 26, 2017 at 10:18 PM, Fuminobu TAKEYAMA wrote:

...

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

...

- "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.

...

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

...

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.

...

- The meta packages does not need "%reconfigure_fonts_prereq"

Sure.

...

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

Hi, On Thu, Apr 27, 2017 at 4:51 PM, Takashi Iwai wrote:

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.

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

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.

...

...

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.

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.co... 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.

...

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'?

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.

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?

...

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.

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

On Fri, Apr 28, 2017 at 12:12 AM, Takashi Iwai wrote

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 :-)

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

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.

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'.

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

...

...

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? 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?

...

...

...

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.

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.

...

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

...

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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, Marguerite Su wrote:

On Fri, Apr 28, 2017 at 12:12 AM, Takashi Iwai wrote

...

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 :-)

...

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

...

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.

...

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'.

...

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

...

...

...

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? 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?

...

...

...

...

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.

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.

...

...

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

...

...

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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 On 2017/05/04 22:32, Takashi Iwai wrote:

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

...

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org

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) On 2017/05/10 4:40, Takashi Iwai wrote:

On Fri, 05 May 2017 14:03:14 +0200, Fuminobu TAKEYAMA wrote:

...

...

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org