Created attachment 670516 [details]
fontconfig file

This fontconfig file will work

Thanks for reporting.  I somehow naively thought this could be done automatically.  In anyway, adding Frederic to Cc.

Your fontconfig looks good to me.  I'll check your config in Japanese locale later and try to add the entries if needed (but maybe in the next week, as we're now in Easter holidays).  Once after that, we can put the fontconfig file into google-noto-fonts package itself.

(In reply to Takashi Iwai from comment #2)
> Thanks for reporting.  I somehow naively thought this could be done
> automatically.  In anyway, adding Frederic to Cc.

Sorry, I thought like Takashi..

> Your fontconfig looks good to me.  I'll check your config in Japanese locale
> later and try to add the entries if needed (but maybe in the next week, as
> we're now in Easter holidays).  Once after that, we can put the fontconfig
> file into google-noto-fonts package itself.

Thanks !

As I can tell so far, fontconfig picks font in an "A-Z" order...so ja_JP locale won't need to modify anything.

maybe the only rule it needs to apply is to substitute "Noto Sans CJK Sans" (some characters are half-width instead of proportional) to "Noto Sans Mono CJK Sans".

And I'm preparing a fix...well 470MB + 89MB are a little huge for my bandwidth...I need them to fix the generate_specfile.sh

Marguerite

OK, I checked the changes in a detail now, and have a few questions:

What's the reason to give the fixed lcdfilter and rgba?  Especially the latter can't be given as a fixed value in general, since this pretty much depends on the monitor you use.

The default hintstyle is OK as long as it's tested.  I assume you compared with different hintstyles, right?  It had been better if this addition was mentioned in the changelog, though, as it influences on appearance a lot.

Regarding the japanese locale: yes, this works as is because of the alphabet order.  But I find it's safer to add it explicitly; partly from the consistency reason and partly from the future-proof reason.

(In reply to Takashi Iwai from comment #5)
> What's the reason to give the fixed lcdfilter and rgba?  Especially the
> latter can't be given as a fixed value in general, since this pretty much
> depends on the monitor you use.

I enabled lcdfilter=light because:

1. For sub-pixel rendering (I think it's almost enabled by most of the CJK users
because our fonts have much more glyphs than western language, so the whole structure
of the body may look ugly, sub-pixel rendering can greatly reduce this), Arch wiki
said "When using subpixel rendering, you should enable the LCD filter, which is designed
to reduce colour fringing" https://wiki.archlinux.org/index.php/font_configuration#LCD_filter
2. For CJK, especially Noto Sans CJK, we can only use "light" filter. actually
default profile renders good, but in Chinese/Japanese we have characters whose
glyphs are too close, like "OSC東京の懇親会は少し特別で", something may be missing
if using default profile because it's too blur in small scale.

about the rgba option, I was wrong about it, the majority of the modern monitors
should use "rgb" instead of "vrgb"...

> The default hintstyle is OK as long as it's tested.  I assume you compared
> with different hintstyles, right?  It had been better if this addition was
> mentioned in the changelog, though, as it influences on appearance a lot.

Actually I didn't test...I just see wqy-microhei-fonts has a fontconfig file
that set hintstyle to hintslight, I think it could be applied on most of 
the CJK fonts.

I'll document it in changelog when I fix the fontconfig file.

> Regarding the japanese locale: yes, this works as is because of the alphabet
> order.  But I find it's safer to add it explicitly; partly from the
> consistency reason and partly from the future-proof reason.

ok, if you want it.

(In reply to Marguerite Su from comment #6)
> (In reply to Takashi Iwai from comment #5)
> > What's the reason to give the fixed lcdfilter and rgba?  Especially the
> > latter can't be given as a fixed value in general, since this pretty much
> > depends on the monitor you use.
> 
> I enabled lcdfilter=light because:
> 
> 1. For sub-pixel rendering (I think it's almost enabled by most of the CJK
> users
> because our fonts have much more glyphs than western language, so the whole
> structure
> of the body may look ugly, sub-pixel rendering can greatly reduce this),
> Arch wiki
> said "When using subpixel rendering, you should enable the LCD filter, which
> is designed
> to reduce colour fringing"
> https://wiki.archlinux.org/index.php/font_configuration#LCD_filter

Yes, that's right to use lcdfilter.  But it's rather a general setting when the subpixel rendering is used, so this can be regarded rather as a global flag, not specific to some font.

> 2. For CJK, especially Noto Sans CJK, we can only use "light" filter.
> actually
> default profile renders good, but in Chinese/Japanese we have characters
> whose
> glyphs are too close, like "OSC東京の懇親会は少し特別で", something may be missing
> if using default profile because it's too blur in small scale.

Hmm, but I guess this isn't specific to Noto, but in general CJK?  If so, setting this shouldn't be specific to Noto.  I'd suggest to remove this from the font-specific setup, but we should improve in general, if needed.
 
> about the rgba option, I was wrong about it, the majority of the modern
> monitors
> should use "rgb" instead of "vrgb"...

OK, let's remove it, too. 

> > The default hintstyle is OK as long as it's tested.  I assume you compared
> > with different hintstyles, right?  It had been better if this addition was
> > mentioned in the changelog, though, as it influences on appearance a lot.
> 
> Actually I didn't test...I just see wqy-microhei-fonts has a fontconfig file
> that set hintstyle to hintslight, I think it could be applied on most of 
> the CJK fonts.

Right, and I thought we applied it somewhere...  At least, in the earlier versions.  If this was really already applied, having it in Noto's config is superfluous, and better to be removed.  For example, once when the rendering by freetype is improved, we can clean it up at once if there is a single setup.

Just my $0.02.

I agree with you on all points. The only problem is that our fontconfig package has no namespace for CJK and subpixel rendering.

We have only nonlatin and non-sub-pixel configs.

We may have to draft new defaults for them (without affecting others).

But how fontconfig knows sub-pixel is enabled (like the locale test)

We have fonts-config script that can preprocess the configuration depending on the setup.  So we may set some values there depending on the global flag.

But it's just an idea, and some other ways might be better, of course.  I guess we can have a consensus at best on ML.  Maybe opensuse-factory ML would be suitable (but of course with some known noises there :) or we can go to m17n ML.

(Adding Petr to Cc so that he'll be informed, too)

First of all, I would vote for reverting this change too, I like more when the package is split.

Settings in /etc/fonts/conf.d/52-noto-sans-cjk.conf is a bit careless. You override all settings done by /etc/sysconfig/fonts-config (~ yast) and even by a personal configuration file, because 52* is read before 56-user.conf and families prepended to the alias from 52* are sooner in the list than that ones prepended (preferred) from 56-user.conf.

1. I would like to have distro default preference done in /etc/fonts/conf.d/60-family-prefer.conf, even locale oriented, similarly you propose (I can help here).

2. I do not see a need for any rendering algorithms tweeks. autohinter with hintslight is chosen anyway by default, as noto is not well instructed font as listed in /etc/fonts/conf.d/10-group-tt-hinted-fonts.conf. Do not use subpixel rendering setting at all, Takashi already said why. Again, all these bits might be set by /etc/sysconfig/fonts-config (~ yast) and should not be overriden by fixed rule for a font (as user will probably to set color hinting for all fonts, if ever).

(In reply to Petr Gajdos from comment #10)
> First of all, I would vote for reverting this change too, I like more when
> the package is split.

Having a combined font is saving a lot of disk space on iso image:
Before the combined font, each cjk was using, as rpm, 72MB + 22MB, ie 94MB, for a total of 376MB
After the combined font, the single package is 71M, so we saving 305MB on iso image.

On installed systems, it is even more saved:
with the separate fonts, for one language: 109MB
all CJK languages: 438MB

combined font: 109MB

so, we are saving up to 29MB on users systems (if they install all CJK, which might not be most of them)..

Yeah, I find the size reduction also attractive, too.

How about just keeping the addition of font prefer per locale?  We need to choose the position in /etc/fonts/conf.d carefully, but it should be doable.
I guess Petr can help this at best.

(In reply to Petr Gajdos from comment #10)
> Settings in /etc/fonts/conf.d/52-noto-sans-cjk.conf is a bit careless. You
> override all settings done by /etc/sysconfig/fonts-config (~ yast) and even
> by a personal configuration file, because 52* is read before 56-user.conf
> and families prepended to the alias from 52* are sooner in the list than
> that ones prepended (preferred) from 56-user.conf.

sorry for that, feel free to change it to any number.

> 1. I would like to have distro default preference done in
> /etc/fonts/conf.d/60-family-prefer.conf, even locale oriented, similarly you
> propose (I can help here).

ok, please inform me when you have the framework done.

> 2. I do not see a need for any rendering algorithms tweeks. autohinter with
> hintslight is chosen anyway by default, as noto is not well instructed font
> as listed in /etc/fonts/conf.d/10-group-tt-hinted-fonts.conf. Do not use
> subpixel rendering setting at all, Takashi already said why. Again, all
> these bits might be set by /etc/sysconfig/fonts-config (~ yast) and should
> not be overriden by fixed rule for a font (as user will probably to set
> color hinting for all fonts, if ever).

Takashi didn't say why. I think, we were discussing the specific options under
the assumption that sub-pixel rendering had been enabled by the user, as those
options will be useless when sub-pixel rendering is disabled.

I know sub-pixel rendering is patent stuff that openSUSE didn't enable. But
I see few CJK users live with the default sub-pixel rendering disabled freetype2.
And I have explained why they want it that much. So please take it as a fact.
Sometimes some needs can't just be satisfied by "don't"s :-(

So, when users have done the most "hard" part that openSUSE can't do, what can
we do to improve Noto's appearance? I was trying to provide such a solution. 

We can move them to some general place that can be overridden by the users with 
YaST.

That is, we have a default non-sub-pixel-rendering settings (those options are stripped
of course since they take no effect or even make things worse), and some place to hold
these for CJK users that have sub-pixel rendering enabled by themselves. I added them
here because I didn't find any place that can achieve this without affect other non-latin
languages.

Marguerite

By the way, I'm not against the usage of the combined font...so don't need to "teach" me why the combined font is good...:-)

(In reply to Takashi Iwai from comment #12)
> How about just keeping the addition of font prefer per locale?  We need to
> choose the position in /etc/fonts/conf.d carefully, but it should be doable.
> I guess Petr can help this at best.

59-* I guess. That is after system and user settings but before distro defaults. Did not test much.

(In reply to Marguerite Su from comment #13)
> (In reply to Petr Gajdos from comment #10)
> Takashi didn't say why. I think, we were discussing the specific options
> under
> the assumption that sub-pixel rendering had been enabled by the user, as
> those
> options will be useless when sub-pixel rendering is disabled.

It was another bug? Maybe I am confusing them all together, sorry. Okay, what you do not know is the subpixel order, which can even change during a program or system run, am I correct? But do not take it wrong, /me is not against turning subpixel rendering by default in fonconfig settings even for all fonts ;). Feel free to communicate on opensuse-factory@.

> I know sub-pixel rendering is patent stuff that openSUSE didn't enable. But
> I see few CJK users live with the default sub-pixel rendering disabled
> freetype2.

Alternatively, consider 13-selective-rendering-cjk.conf where would be subpixel rendering turned on for cjk locales. Anyway, turning on subpixel rendering for one particular font seems odd to me.

(In reply to Petr Gajdos from comment #16)
> It was another bug? Maybe I am confusing them all together, sorry. Okay,
> what you do not know is the subpixel order, which can even change during a
> program or system run, am I correct? But do not take it wrong, /me is not
> against turning subpixel rendering by default in fonconfig settings even for
> all fonts ;). Feel free to communicate on opensuse-factory@.

Nope. here's the thing:

1. I created 52-noto-sans-cjk.conf which contains settings for hintstyle, rgba, lcdfilter.
2. tiwai wonders why, I said this is for better appearance. 
3. he said it shouldn't be here but in a more general place where we all don't know
4. he CC-ed you to help with such place.

These settings for hintstyle, rgba, lcdfilter can be applied on all CJK fonts.
But we don't know where's the place for this.

Yes, I don't know the specific user's sub-pixel order, but most of the modern
monitor's sub-pixel order is known, that is, "rgba" option's "best-effort" setting
should be "rgb". I think "most" is good for us, or most of the fontconfig settings
can't be there because developer will never know what fonts are installed on any
specific user's system, eg someone may not install libration-sans at all. "best
guess" is enough in preparing default setting.

> Alternatively, consider 13-selective-rendering-cjk.conf where would be
> subpixel rendering turned on for cjk locales. Anyway, turning on subpixel
> rendering for one particular font seems odd to me.

Yes, I realized that too. I think 13-selective-rendering-cjk.conf is good to me.
it can be used as a place for CJK developers to optimize appearance of CJK fonts,
just like 65-fonts-persian.conf.

But how do you know when 13-selective-rendering-cjk.conf is loaded, the sub-pixel
rendering is also on?

I see many cdefault onfigurations like:

10-sub-pixel-bgr.conf
10-sub-pixel-rgb.conf
10-sub-pixel-vbgr.conf
10-sub-pixel-vrgb.conf
11-lcdfilter-default.conf
11-lcdfilter-legacy.conf
11-lcdfilter-light.conf

I think there must be a condition that one of these configurations will get loaded.

(In reply to Petr Gajdos from comment #16)
> It was another bug? Maybe I am confusing them all together, sorry. Okay,

https://bugzilla.suse.com/show_bug.cgi?id=862591#c13

and previous comments.

It took a while to find it ;).

(In reply to Marguerite Su from comment #17)
> 10-sub-pixel-bgr.conf
> 10-sub-pixel-rgb.conf
> 10-sub-pixel-vbgr.conf
> 10-sub-pixel-vrgb.conf
> 11-lcdfilter-default.conf
> 11-lcdfilter-legacy.conf
> 11-lcdfilter-light.conf
> 
> I think there must be a condition that one of these configurations will get
> loaded.


Yes, the condition is a link to /etc/fonts/conf.d/.

(Colleague of mine has two identical monitors, one of them rotated 90°. :))

Well, let's leave the subpixel and lcdfilter issues away, but concentrate only on fixing CJK issues in this bug entry.  The rest issues are really irrelevant from the original bug.

Marguerite, could you resubmit the fixed package with a reduced fontconfig that contains only CJK aliases, and put in 59-* ?  Then we can test it on a real system, too.  Thanks.

(In reply to Takashi Iwai from comment #20)
> Marguerite, could you resubmit the fixed package with a reduced fontconfig
> that contains only CJK aliases, and put in 59-* ?  Then we can test it on a
> real system, too.  Thanks.

Done

Thanks, now it was already submitted to FACTORY.

So, let's fix this bug for now.  The rest issues about subpixel and other options should be discussed in other channels, as they are basically irrelevant from the original bug.