On Tue, 11 Apr 2017 17:15:26 +0200, Marguerite Su wrote:
On Sun, Apr 9, 2017 at 3:47 PM, Takashi Iwai <tiwai@suse.de> 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