Re: [RFC]refactor Noto CJK fonts packaging

On Tue, 11 Apr 2017 17:15:26 +0200,
Marguerite Su wrote:
> 
> On Sun, Apr 9, 2017 at 3:47 PM, Takashi Iwai <[email protected]> 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: [email protected]
To contact the owner, e-mail: [email protected]