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 Sat, 08 Apr 2017 11:52:43 +0200, Marguerite Su wrote:

On Sat, Apr 8, 2017 at 5:09 PM, Takashi Iwai wrote:

...

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?

Yes. Otherwise it appears strange to me.

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.

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

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.

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.

...

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.

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

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

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

On Mon, 10 Apr 2017 10:30:18 +0200, Frederic Crozat wrote:

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 ? 

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.

...

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

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

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.

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.

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 On 2017年04月08日 17:30, Marguerite Su wrote:

Hi, Fuminobu,

On Sat, Apr 8, 2017 at 4:18 PM, Fuminobu TAKEYAMA wrote:

...

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

...

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?

...

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

...

...

4. the symbol part.

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

On Tue, Apr 11, 2017 at 6:53 PM, Stefan Knorr wrote:

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.

Thanks Stefan, One more thing, Please add Petr Gajdos to M17N team too, he is the maintainer for fonts-config from SLE side. I don't want him think that I took over his project and made a new upstream. So please give him write permission to the repo too. I'll let you know if anyone wants to join M17N team on github Because I tested and I have no permission to add people to a group. Marguerite -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org