Re: [RFC]refactor Noto CJK fonts packaging

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 =E9=97=A8 from we=
b, it'll be
different when you paste it on your local system.

Then it becomes a valid bug actually.

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

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

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

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

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

Takashi, I visit this page: https://ja.wiktionary.org/wiki/%E9%97%A8,
and copy the the word
you see, and it becomes =E9=97=A8 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 imple=
ments
that feature (OpenType locl GSUB)

> 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 fi=
x.

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

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

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

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

It's not for fontconfig at all.

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


> 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 =3D=3D> 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.

Marguerite
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]