[Bug 502610]
> So how about listing sans-serif (Hei) before bitmap then?
Bitmaps are more like a compromise to poor hinting tech (could not
handle the high stroke densities in Han (especially Hant) glyphs) +
small pixel sizes (and perhaps small disk space) in the old days.
Vectors can get rendered into a mess of black-and-white, so bitmaps were
actually giving better legibility.
Now we have sfdhanautohint, HiDPI screens and bigger disks, so perhaps
the only places for bitmaps to go are terminals and TTYs (Unibit
actually worked very well for me.)
> There is also a 69-unifont.conf, probably the differences between
these unifonts and cjk fonts are not that big.
I was confused by all these "unifont"s at first. It seems that GNU has a
"Unifont" which was mostly 16x16 pixel glyphs, and Arphic has something
called CJKUnifonts (UMing, UKai), while the config file is more like
listing some catch-all Unicode fallback fonts.
> Because 65-nonlatin puts many
> Japanese fonts in front of Chinese fonts, when rendering a block of text with
> Han glyphs, one often see a mixture of Gothic, Mincho, Song and Kai glyphs,
> which looks horrible.
See my previous comment -- this has nothing to do with locale mixing.
And Mincho is just Song. (See #Generics.)
> I suggest to put Chinese fonts in front of Japanese/Korean fonts.
> [...] consistent [...]
Previous comment gives a different rationale for this.
> Giving a higher priority to proprietary fonts
And nowadays many FOSS fonts look better than all these old proprietary
favourites. (Sounds wise to kick them out directly now.)
* * *
Generics
* Gothic is basically sans (just like western typography).
* Dotum{,Che} (rectangle hangul edges) and Gulim (round hangul edges) are
Korean sans-serifs.
* Mincho is just "Ming Dynasty", i.e. Ming, which is actually when the "Song"
(the Chinese dynasty after Ming) typefaces got its basic distinct shapes from
Kai.
* Ming is just how people in non-mainland-China areas refer to Song/Sung. That
includes Japan (Mincho), Taiwan, HK and Macau. Since it's kind of more correct
historically, I prefer this name too.
* Batang (i.e. "basic" according to zh.wikipedia) is a Korean Ming.
* Kai is the most common Chinese script style, which is written neatly. Chinese
cursive is called Cao (草), and Xing (行) is between the two. (XingKai is the
more Kai-ish branch of Xing, the other one being XingCao.)
It then seems unwise to refer to typefaces using these locale-and-
vendor-dependent names rather than "sans-serif", "serif" and "cursive"
in logical fallback orders, with locale ordered discussed separately.
I am using Kai to match cursive because:
a. There are few Cao typefaces. (Complex ligations, adaptations to vertical
writing...)
b. Cao is hardly legible.
c. Kai is very common (and available in FOSS forms -- unlike XingKai), and
since people actually use "Comic Sans" to match cursive it doesn't sound too
bad to me.
Scripts
---
And some info on scripts that we have mentioned:
* Han/Kanji/Hanja: CJK Ideographs, e.g. 字体 (Hans)，字體 (Hant). The good news is
that despite different writing standards, most simplified characters are not
unified with their traditional forms, so most of the differences are tolerable.
Bad news? Japanese have largely simplified their Han set on their side too (in
1946, with a great reduction to ~2K chars), and unfortunately unification with
CN is seen in chars like 门.
* Hangul = "Hang": Korean phonetic alphabet mostly made up of Han strokes and
circles.
* Kana = "Hrkt": Japanese phonetic alphabet with shapes originally sourced from
simplifications of Chinese glyphs with the target pronunciations. There are two
sets of Kana -- hiragana "Hira" (for native words) and katakana "Kana" (for
foreign words mainly).
Many everyday Korean text only consist of Hanguls, while most Japanese
text show a mix of Kanjis and Kanas.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/502610
Title:
Chinese characters unexpectedly switch fonts in WebKit-GTK
To manage notifications about this bug go to:
https://bugs.launchpad.net/fontconfig/+bug/502610/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 502610]
Silly mistake spotted. > which is actually when the "Song" (the Chinese dynasty after Ming) Song is before Ming, which follows Yuan (Mongolian rule). During the Song dynasty, the printing industry reached an apex, thanks to movable type. By Ming, the Kai-script-like typeface for movable blocks used during Song have evolved into a simpler form with straight strokes (like Modern Ming), which is much easier to carve on wood blocks. * * * Jeff Bai and I have almost forgotten the issue... Fortunately the pending list generally looks good for me by now, and I am hoping to publish it by next Monday. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/502610 Title: Chinese characters unexpectedly switch fonts in WebKit-GTK To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/502610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 502610]
Jeff Bai and I are currently working on a newer ordering of this file for the CJK part at https://github.com/AOSC-Dev /aosc-os-abbs/issues/201. Hopefully we will come up with a modernized version this weekend or so. We are mainly focused on these points: * Separate sans (hei), serif (ming/song) and cursive (kai). Like the current git version of the file, we are now only adding strongly monospace (i.e. monospace for non-han parts too) fonts as monospace, but this is actually worth a discussion IFF the font is only going to provide CJK chars. (We know at least FW kanas and hanzi/kanjis are always 1em wide (good), while some hanguls are like .93 em (oops).) * Font weight matching. Many old CJK serifs (e.g. UMing, SimSun) look too thin to match common serifs, but the TeX community have good fonts to remedy this -- cwTeX and Fandol fonts. We add [kind of prepend, in CJK ranges] these fonts to the list accordingly. As a bonus, these are all FOSS. Some CJK sans on the other hand is too heavy (e.g. SimHei[1]), but now we have Noto Sans CJK/Source Han Sans to remedy this. * Sans-serif monospace is better than serif monospace, at least for computer screens. Additionally, monospace CJK serifs are often old and have the very-thin-weight issue. Note that we are not supposed to nor intending to fix any of these "locale mix" problems like what was shown in the description of attachment 24321. Locale matching problems should be done via in-browser detection schemes like html lang tags, with appropriate locale-aware requests to fc, which hopefully will be handled by other distro-specific config wiles. We are only trying to make sure the styles of CJK part matches latin fonts matched for the generic family names, as well as themselves. (This is actually a terrible problem on MS Windows, where they consider SimSun a sans-serif.) (Well, considering the widths of some glyphs like 复 in Japanese fonts (they are often not actually using the glyphs in the language but using it as some glyph to be referenced by other glyphs), I will go with TW, KR or CN fonts as the preferred source of Chinese glyphs. Choosing the traditional locales is just for "going back the roots and be acceptable to as many locales as possible". (KR glyphs are kind of old/kangxi-ish- style -- lack of use lead to lack of evolution.)) [1]: In Chinese, Hei (黑) stands for black. This actually caused some confusion and resulted in many people calling bold weights "Hei". I have no idea on how to fix the bad "ja" language tags in Chinese fonts though. (why are they trying to eat manage everything?) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/502610 Title: Chinese characters unexpectedly switch fonts in WebKit-GTK To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/502610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 521163]
> So how about listing sans-serif (Hei) before bitmap then?
Bitmaps are more like a compromise to poor hinting tech (could not
handle the high stroke densities in Han (especially Hant) glyphs) +
small pixel sizes (and perhaps small disk space) in the old days.
Vectors can get rendered into a mess of black-and-white, so bitmaps were
actually giving better legibility.
Now we have sfdhanautohint, HiDPI screens and bigger disks, so perhaps
the only places for bitmaps to go are terminals and TTYs (Unibit
actually worked very well for me.)
> There is also a 69-unifont.conf, probably the differences between
these unifonts and cjk fonts are not that big.
I was confused by all these "unifont"s at first. It seems that GNU has a
"Unifont" which was mostly 16x16 pixel glyphs, and Arphic has something
called CJKUnifonts (UMing, UKai), while the config file is more like
listing some catch-all Unicode fallback fonts.
> Because 65-nonlatin puts many
> Japanese fonts in front of Chinese fonts, when rendering a block of text with
> Han glyphs, one often see a mixture of Gothic, Mincho, Song and Kai glyphs,
> which looks horrible.
See my previous comment -- this has nothing to do with locale mixing.
And Mincho is just Song. (See #Generics.)
> I suggest to put Chinese fonts in front of Japanese/Korean fonts.
> [...] consistent [...]
Previous comment gives a different rationale for this.
> Giving a higher priority to proprietary fonts
And nowadays many FOSS fonts look better than all these old proprietary
favourites. (Sounds wise to kick them out directly now.)
* * *
Generics
* Gothic is basically sans (just like western typography).
* Dotum{,Che} (rectangle hangul edges) and Gulim (round hangul edges) are
Korean sans-serifs.
* Mincho is just "Ming Dynasty", i.e. Ming, which is actually when the "Song"
(the Chinese dynasty after Ming) typefaces got its basic distinct shapes from
Kai.
* Ming is just how people in non-mainland-China areas refer to Song/Sung. That
includes Japan (Mincho), Taiwan, HK and Macau. Since it's kind of more correct
historically, I prefer this name too.
* Batang (i.e. "basic" according to zh.wikipedia) is a Korean Ming.
* Kai is the most common Chinese script style, which is written neatly. Chinese
cursive is called Cao (草), and Xing (行) is between the two. (XingKai is the
more Kai-ish branch of Xing, the other one being XingCao.)
It then seems unwise to refer to typefaces using these locale-and-
vendor-dependent names rather than "sans-serif", "serif" and "cursive"
in logical fallback orders, with locale ordered discussed separately.
I am using Kai to match cursive because:
a. There are few Cao typefaces. (Complex ligations, adaptations to vertical
writing...)
b. Cao is hardly legible.
c. Kai is very common (and available in FOSS forms -- unlike XingKai), and
since people actually use "Comic Sans" to match cursive it doesn't sound too
bad to me.
Scripts
---
And some info on scripts that we have mentioned:
* Han/Kanji/Hanja: CJK Ideographs, e.g. 字体 (Hans)，字體 (Hant). The good news is
that despite different writing standards, most simplified characters are not
unified with their traditional forms, so most of the differences are tolerable.
Bad news? Japanese have largely simplified their Han set on their side too (in
1946, with a great reduction to ~2K chars), and unfortunately unification with
CN is seen in chars like 门.
* Hangul = "Hang": Korean phonetic alphabet mostly made up of Han strokes and
circles.
* Kana = "Hrkt": Japanese phonetic alphabet with shapes originally sourced from
simplifications of Chinese glyphs with the target pronunciations. There are two
sets of Kana -- hiragana "Hira" (for native words) and katakana "Kana" (for
foreign words mainly).
Many everyday Korean text only consist of Hanguls, while most Japanese
text show a mix of Kanjis and Kanas.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/521163
Title:
WenQuanYi Zen Hei is prioritised above Japanese fonts for Japanese
language text
To manage notifications about this bug go to:
https://bugs.launchpad.net/fontconfig/+bug/521163/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 521163]
Jeff Bai and I are currently working on a newer ordering of this file for the CJK part at https://github.com/AOSC-Dev /aosc-os-abbs/issues/201. Hopefully we will come up with a modernized version this weekend or so. We are mainly focused on these points: * Separate sans (hei), serif (ming/song) and cursive (kai). Like the current git version of the file, we are now only adding strongly monospace (i.e. monospace for non-han parts too) fonts as monospace, but this is actually worth a discussion IFF the font is only going to provide CJK chars. (We know at least FW kanas and hanzi/kanjis are always 1em wide (good), while some hanguls are like .93 em (oops).) * Font weight matching. Many old CJK serifs (e.g. UMing, SimSun) look too thin to match common serifs, but the TeX community have good fonts to remedy this -- cwTeX and Fandol fonts. We add [kind of prepend, in CJK ranges] these fonts to the list accordingly. As a bonus, these are all FOSS. Some CJK sans on the other hand is too heavy (e.g. SimHei[1]), but now we have Noto Sans CJK/Source Han Sans to remedy this. * Sans-serif monospace is better than serif monospace, at least for computer screens. Additionally, monospace CJK serifs are often old and have the very-thin-weight issue. Note that we are not supposed to nor intending to fix any of these "locale mix" problems like what was shown in the description of attachment 24321. Locale matching problems should be done via in-browser detection schemes like html lang tags, with appropriate locale-aware requests to fc, which hopefully will be handled by other distro-specific config wiles. We are only trying to make sure the styles of CJK part matches latin fonts matched for the generic family names, as well as themselves. (This is actually a terrible problem on MS Windows, where they consider SimSun a sans-serif.) (Well, considering the widths of some glyphs like 复 in Japanese fonts (they are often not actually using the glyphs in the language but using it as some glyph to be referenced by other glyphs), I will go with TW, KR or CN fonts as the preferred source of Chinese glyphs. Choosing the traditional locales is just for "going back the roots and be acceptable to as many locales as possible". (KR glyphs are kind of old/kangxi-ish- style -- lack of use lead to lack of evolution.)) [1]: In Chinese, Hei (黑) stands for black. This actually caused some confusion and resulted in many people calling bold weights "Hei". I have no idea on how to fix the bad "ja" language tags in Chinese fonts though. (why are they trying to eat manage everything?) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/521163 Title: WenQuanYi Zen Hei is prioritised above Japanese fonts for Japanese language text To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/521163/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 521163]
Silly mistake spotted. > which is actually when the "Song" (the Chinese dynasty after Ming) Song is before Ming, which follows Yuan (Mongolian rule). During the Song dynasty, the printing industry reached an apex, thanks to movable type. By Ming, the Kai-script-like typeface for movable blocks used during Song have evolved into a simpler form with straight strokes (like Modern Ming), which is much easier to carve on wood blocks. * * * Jeff Bai and I have almost forgotten the issue... Fortunately the pending list generally looks good for me by now, and I am hoping to publish it by next Monday. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/521163 Title: WenQuanYi Zen Hei is prioritised above Japanese fonts for Japanese language text To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/521163/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1638959] Re: Consider updating from 2.12 RC4 to 2.12.1 for 17.04
Adding inkscape-devlibs64 for a similar update, per https://bazaar.launchpad.net/~inkscape.dev/inkscape- devlibs64/trunk/view/head:/readme.txt. (What is FreeType 2 18.2.12, by the way?) ** Also affects: inkscape-devlibs64 Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1638959 Title: Consider updating from 2.12 RC4 to 2.12.1 for 17.04 To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape-devlibs64/+bug/1638959/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1595414] Re: Awful system-wise generic selection for CJK
My current suggestion is to construct a test HTML like this:
UKai/UMing test
/* Change the needle font here */
body { font-family: sans-serif; }
漢字汉字 @ zh
漢字汉字 @ ja
漢字汉字 @ en
After removing UKai from my system, it begins to show UMing.
* * *
> as far as I can retell,
should be "recall". Well since I re-installed these troublemakers to
write the other half of the report, just pretend that these words don't
exist (I verified these observations.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1595414
Title:
Awful generic selection for zh in Firefox
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fonts-arphic-ukai/+bug/1595414/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1595414] Re: Awful system-wise generic selection for CJK
Just an uninteresting side note, setting font-family to either 'Monospace' or monospace in the test case above shows a very proportional font for ja. This should be a separate report, but just in case I forget: $ LC_ALL='ja_JP.UTF-8' fc-match 'Monospace' DroidSansFallbackFull.ttf: "Droid Sans Fallback" "Regular" ** Summary changed: - Awful system-wise generic selection for CJK + Awful generic selection for zh in Firefox -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1595414 Title: Awful generic selection for zh in Firefox To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fonts-arphic-ukai/+bug/1595414/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1595414] [NEW] Awful system-wise generic selection for CJK
Public bug reported: In https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/fonts- arphic-ukai/wily/revision/6, UMing and UKai are set as generics for fonts. However, this set of generics is completely intolerable -- setting UKai as a generic is like setting Zapfino and/or Comic Sans as a system-wise generic, while UMing as a normal (just a bit thin) serif sounds a bit better. This yields terrible results on non-Chinese systems with non-Chinese lang-attributed websites, like Twitter, on Ubuntu 14.04 LTS after installing Chinese language support which includes the two arphic fonts mentioned in this report. This problem is similar to https://bugs.freedesktop.org/show_bug.cgi?id=20911, a long-standing system-global fontconfig non-latin fallback problem. See also bug #1560548 where these generic settings are considered as 'redundant' and proposed for deletion. I have mentioned a third-person report about such selection in #1560548 previously, but I have just reproduced this bug by myself by installing zh-cn support by mistake. ** Affects: fonts-arphic-ukai (Ubuntu) Importance: Undecided Status: New ** Affects: fonts-arphic-uming (Ubuntu) Importance: Undecided Status: New ** Also affects: fonts-arphic-ukai (Ubuntu) Importance: Undecided Status: New ** Description changed: In https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/fonts- arphic-ukai/wily/revision/6, UMing and UKai are set as generics for fonts. However, this set of generics is completely intolerable -- setting UKai as a generic is like setting Zapfino and/or Comic Sans as a system-wise generic, while UMing as a normal (just a bit thin) serif sounds a bit better. This yields terrible results on non-Chinese systems with non-Chinese lang-attributed websites, like Twitter, at least on Ubuntu 14.04 LTS after installing Chinese language support which includes the two arphic fonts mentioned in this report. This problem is similar to https://bugs.freedesktop.org/show_bug.cgi?id=20911, a long-standing - system-global fontconfig non-latin fallback problem. See also #1560548 - where these generic settings are considered as 'unneeded' and proposed - for deletion. I have mentioned a third-person report about such + system-global fontconfig non-latin fallback problem. See also bug + #1560548 where these generic settings are considered as 'unneeded' and + proposed for deletion. I have mentioned a third-person report about such selection in #1560548 previously, but I have just reproduced this bug by myself by installing zh-cn support by mistake. ** Description changed: In https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/fonts- arphic-ukai/wily/revision/6, UMing and UKai are set as generics for fonts. However, this set of generics is completely intolerable -- setting UKai as a generic is like setting Zapfino and/or Comic Sans as a system-wise generic, while UMing as a normal (just a bit thin) serif sounds a bit better. This yields terrible results on non-Chinese systems - with non-Chinese lang-attributed websites, like Twitter, at least on - Ubuntu 14.04 LTS after installing Chinese language support which - includes the two arphic fonts mentioned in this report. + with non-Chinese lang-attributed websites, like Twitter, on Ubuntu 14.04 + LTS after installing Chinese language support which includes the two + arphic fonts mentioned in this report. This problem is similar to https://bugs.freedesktop.org/show_bug.cgi?id=20911, a long-standing system-global fontconfig non-latin fallback problem. See also bug #1560548 where these generic settings are considered as 'unneeded' and proposed for deletion. I have mentioned a third-person report about such selection in #1560548 previously, but I have just reproduced this bug by myself by installing zh-cn support by mistake. ** Description changed: In https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/fonts- arphic-ukai/wily/revision/6, UMing and UKai are set as generics for fonts. However, this set of generics is completely intolerable -- setting UKai as a generic is like setting Zapfino and/or Comic Sans as a system-wise generic, while UMing as a normal (just a bit thin) serif sounds a bit better. This yields terrible results on non-Chinese systems with non-Chinese lang-attributed websites, like Twitter, on Ubuntu 14.04 LTS after installing Chinese language support which includes the two arphic fonts mentioned in this report. This problem is similar to https://bugs.freedesktop.org/show_bug.cgi?id=20911, a long-standing system-global fontconfig non-latin fallback problem. See also bug - #1560548 where these generic settings are considered as 'unneeded' and + #1560548 where these generic settings are considered as 'redundant' and proposed for deletion. I have mentioned a third-person report about such selection in #1560548 previously, but I have just reproduced
[Bug 1578749] Re: fontconfig substitutes not considered by libgdiplus
Regarding that test case, consider resizing the button explicitly or just use the CJK string "我是方框。", since the button by default has a fixed size. In https://github.com/AOSC-Dev/aosc-os-abbs/issues/224, JeffBai (github:MingcongBai) found out that using pango does fix the problem. The pango linking LDFLAGS in configure was a little bit off however -- we appended '-lm -lpangoft2-1.0' to LDFLAGS explicitly after configure to deal with link failures. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1578749 Title: fontconfig substitutes not considered by libgdiplus To manage notifications about this bug go to: https://bugs.launchpad.net/libgdiplus/+bug/1578749/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1578749] Re: fontconfig substitutes not considered by libgdiplus
** Description changed:
libgdiplus' cairo backend only takes the fontconfig *match* to render
glyphs in cairo, with zero considerations for substitutes. This causes
significant problems when a developer using WinForms tries to display
some CJK glyphs in "Sans", while expecting system-like handling for
these bugs. Tofus will show up in such cases if the first candidate
generated from `fc-match Sans` is not a font with CJK glyphs.
- This modified version of WinForms 'hello world' should be able to show
- this bug:
+ This modified version of WinForms 'hello world' should be able to show this
bug when fc-match satisfies the said conditions:
+ (Consider changing "Sans" to non-CJK fonts like "Liberation Sans" for stable
reproduction.)
```C#
using System;
using System.Drawing;
using System.Windows.Forms;
public class HelloWorld : Form
{
static public void Main ()
{
Application.Run (new HelloWorld ());
}
public HelloWorld ()
{
Button b = new Button ();
b.Text = "Tofus? → 我是方框。";
b.Font = new Font("Sans", 11);
b.Click += new EventHandler (Button_Click);
Controls.Add (b);
}
private void Button_Click (object sender, EventArgs e)
{
MessageBox.Show ("Does it taste good?");
}
}
```
Note this problem is not limited to "Sans", nor CJK chars -- I am just
using these for a common-enough example. In real life developers trying
to do cross-platform Winforms development might instead just use the
default fonts ("MS Sans Serif" or "Tahoma" on Mono), and still bump into
the very same blocks of tofu, perhaps with the emojis sent by their
happy users.
A possible workaround is to try the experimental pango backend, but that
is really very experimental. There is a pending PR at
https://github.com/mono/libgdiplus/pull/39, which is said to be
"basically approved" back in 2009. (Yeah, mono devs are getting tired of
desktop it seems.)
** Description changed:
libgdiplus' cairo backend only takes the fontconfig *match* to render
glyphs in cairo, with zero considerations for substitutes. This causes
significant problems when a developer using WinForms tries to display
some CJK glyphs in "Sans", while expecting system-like handling for
these bugs. Tofus will show up in such cases if the first candidate
generated from `fc-match Sans` is not a font with CJK glyphs.
This modified version of WinForms 'hello world' should be able to show this
bug when fc-match satisfies the said conditions:
- (Consider changing "Sans" to non-CJK fonts like "Liberation Sans" for stable
reproduction.)
+ (Consider changing "Sans" to non-CJK fonts like "Liberation Sans" for stable
reproduction. "Sans" is usually easier to mess with (by specifying LC_ALL, for
example) though.)
```C#
using System;
using System.Drawing;
using System.Windows.Forms;
public class HelloWorld : Form
{
static public void Main ()
{
Application.Run (new HelloWorld ());
}
public HelloWorld ()
{
Button b = new Button ();
b.Text = "Tofus? → 我是方框。";
b.Font = new Font("Sans", 11);
b.Click += new EventHandler (Button_Click);
Controls.Add (b);
}
private void Button_Click (object sender, EventArgs e)
{
MessageBox.Show ("Does it taste good?");
}
}
```
Note this problem is not limited to "Sans", nor CJK chars -- I am just
using these for a common-enough example. In real life developers trying
to do cross-platform Winforms development might instead just use the
default fonts ("MS Sans Serif" or "Tahoma" on Mono), and still bump into
the very same blocks of tofu, perhaps with the emojis sent by their
happy users.
A possible workaround is to try the experimental pango backend, but that
is really very experimental. There is a pending PR at
https://github.com/mono/libgdiplus/pull/39, which is said to be
"basically approved" back in 2009. (Yeah, mono devs are getting tired of
desktop it seems.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1578749
Title:
fontconfig substitutes not considered by libgdiplus
To manage notifications about this bug go to:
https://bugs.launchpad.net/libgdiplus/+bug/1578749/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1578749] [NEW] fontconfig substitutes not considered by libgdiplus
Public bug reported:
libgdiplus' cairo backend only takes the fontconfig *match* to render
glyphs in cairo, with zero considerations for substitutes. This causes
significant problems when a developer using WinForms tries to display
some CJK glyphs in "Sans", while expecting system-like handling for
these bugs. Tofus will show up in such cases if the first candidate
generated from `fc-match Sans` is not a font with CJK glyphs.
This modified version of WinForms 'hello world' should be able to show
this bug:
```C#
using System;
using System.Drawing;
using System.Windows.Forms;
public class HelloWorld : Form
{
static public void Main ()
{
Application.Run (new HelloWorld ());
}
public HelloWorld ()
{
Button b = new Button ();
b.Text = "Tofus? → 我是方框。";
b.Font = new Font("Sans", 11);
b.Click += new EventHandler (Button_Click);
Controls.Add (b);
}
private void Button_Click (object sender, EventArgs e)
{
MessageBox.Show ("Does it taste good?");
}
}
```
Note this problem is not limited to "Sans", nor CJK chars -- I am just
using these for a common-enough example. In real life developers trying
to do cross-platform Winforms development might instead just use the
default fonts ("MS Sans Serif" or "Tahoma" on Mono), and still bump into
the very same blocks of tofu, perhaps with the emojis sent by their
happy users.
A possible workaround is to try the experimental pango backend, but that
is really very experimental. There is a pending PR at
https://github.com/mono/libgdiplus/pull/39, which is said to be
"basically approved" back in 2009. (Yeah, mono devs are getting tired of
desktop it seems.)
** Affects: libgdiplus
Importance: Unknown
Status: Unknown
** Affects: libgdiplus (Ubuntu)
Importance: Undecided
Status: New
** Bug watch added: bugzilla.xamarin.com/ #39418
http://bugzilla.xamarin.com/show_bug.cgi?id=39418
** Also affects: libgdiplus via
http://bugzilla.xamarin.com/show_bug.cgi?id=39418
Importance: Unknown
Status: Unknown
** Description changed:
libgdiplus' cairo backend only takes the fontconfig *match* to render
glyphs in cairo, with zero considerations for substitutes. This causes
significant problems when a developer using WinForms tries to display
some CJK glyphs in "Sans", while expecting system-like handling for
these bugs. Tofus will show up in such cases if the first candidate
generated from `fc-match Sans` is not a font with CJK glyphs.
This modified version of WinForms 'hello world' should be able to show
this bug:
```C#
using System;
using System.Drawing;
using System.Windows.Forms;
public class HelloWorld : Form
{
- static public void Main ()
- {
- Application.Run (new HelloWorld ());
- }
+ static public void Main ()
+ {
+ Application.Run (new HelloWorld ());
+ }
- public HelloWorld ()
- {
- Button b = new Button ();
- b.Text = "Tofus? → 我是方框。";
- b.Font = new Font("Sans", 11);
- b.Click += new EventHandler (Button_Click);
- Controls.Add (b);
- }
+ public HelloWorld ()
+ {
+ Button b = new Button ();
+ b.Text = "Tofus? → 我是方框。";
+ b.Font = new Font("Sans", 11);
+ b.Click += new EventHandler (Button_Click);
+ Controls.Add (b);
+ }
- private void Button_Click (object sender, EventArgs e)
- {
- MessageBox.Show ("Button Clicked!");
- }
+ private void Button_Click (object sender, EventArgs e)
+ {
+ MessageBox.Show ("Does it taste good?");
+ }
}
```
Note this problem is not limited to "Sans", nor CJK chars -- I am just
using these for a common-enough example. In real life developers trying
to do cross-platform Winforms development might instead just use the
default fonts ("MS Sans Serif" or "Tahoma" on Mono), and still bump into
the very same blocks of tofu, perhaps with the emojis sent by their
happy users.
A possible workaround is to try the experimental pango backend, but that
is really very experimental. There is a pending PR at
https://github.com/mono/libgdiplus/pull/39, which is said to be
"basically approved" back in 2009. (Yeah, mono devs are getting tired of
desktop it seems.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1578749
Title:
fontconfig substitutes not considered by libgdiplus
To manage notifications about this bug go to:
https://bugs.launchpad.net/libgdiplus/+bug/1578749/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1577241] [NEW] Sys.Drawing.SystemFonts does not return UI fonts being used in system
Public bug reported: The current mono implementation of System.Drawing.SystemFonts is hard- coded to return "Microsoft Sans Serif" and "Tahoma" for system font queries. Even though this matches MSDN-documented values for Windows, this violates the intended semantics of this class, and produces surprises for cross-platform Winforms developers. With fontconfig usage in libgdiplus, a quick and (kind of) dirty fix is to replace them with "Sans" (or "Ubuntu" if you want to.) A more MSDN-friendly solution[1] is to return GenericSansSerif directly, however this ends up pointing to libgdiplus's implementation which ends up giving MS Sans Serif too. [1]: https://msdn.microsoft.com/en-us/library/system.drawing.systemfonts.defaultfont(v=vs.110).aspx A related workaround in fontconfig is to alias Microsoft Sans Serif to Helvetica in 30-metric-aliases.conf (fd.o 95232). This should at least solve the issue that fontconfig most likely knows nothing about matching "Microsoft Sans Serif". ** Affects: mono Importance: Unknown Status: Unknown ** Affects: mono (Ubuntu) Importance: Undecided Status: New ** Bug watch added: bugzilla.xamarin.com/ #40791 http://bugzilla.xamarin.com/show_bug.cgi?id=40791 ** Also affects: mono via http://bugzilla.xamarin.com/show_bug.cgi?id=40791 Importance: Unknown Status: Unknown ** Description changed: The current mono implementation of System.Drawing.SystemFonts is hard- coded to return "Microsoft Sans Serif" and "Tahoma" for system font queries. Even though this matches MSDN-documented values for Windows, - this violates the intended semantics of this class. + this violates the intended semantics of this class, and produces + surprises for cross-platform Winforms developers. With fontconfig usage in libgdiplus, a quick and (kind of) dirty fix is to replace them with "Sans" (or "Ubuntu" if you want to.) A more MSDN-friendly solution[1] is to return GenericSansSerif directly, however this ends up pointing to libgdiplus's implementation which ends up giving MS Sans Serif too. - [1]: https://msdn.microsoft.com/en-us/library/system.drawing.systemfonts.defaultfont(v=vs.110).aspx + [1]: https://msdn.microsoft.com/en-us/library/system.drawing.systemfonts.defaultfont(v=vs.110).aspx A related workaround in fontconfig is to alias Microsoft Sans Serif to Helvetica in 30-metric-aliases.conf (fd.o 95232). ** Description changed: The current mono implementation of System.Drawing.SystemFonts is hard- coded to return "Microsoft Sans Serif" and "Tahoma" for system font queries. Even though this matches MSDN-documented values for Windows, this violates the intended semantics of this class, and produces surprises for cross-platform Winforms developers. With fontconfig usage in libgdiplus, a quick and (kind of) dirty fix is to replace them with "Sans" (or "Ubuntu" if you want to.) A more MSDN-friendly solution[1] is to return GenericSansSerif directly, however this ends up pointing to libgdiplus's implementation which ends up giving MS Sans Serif too. [1]: https://msdn.microsoft.com/en-us/library/system.drawing.systemfonts.defaultfont(v=vs.110).aspx A related workaround in fontconfig is to alias Microsoft Sans Serif to - Helvetica in 30-metric-aliases.conf (fd.o 95232). + Helvetica in 30-metric-aliases.conf (fd.o 95232). This should at least + solve the issue that fontconfig most likely knows nothing about matching + "Microsoft Sans Serif". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577241 Title: Sys.Drawing.SystemFonts does not return UI fonts being used in system To manage notifications about this bug go to: https://bugs.launchpad.net/mono/+bug/1577241/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1462311] Re: proftpd mod_copy issue (CVE-2015-3306)
** Description changed: The CVE-2015-3306 problem is arround for some time now and is not fixed in 12.04 and 14.04 LTS versions. http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-3306.html I also tested it with telnet. I can copy files without any authentication if mod_copy is enabled (mod_copy is per default enabled!) The module is very usefull. I would be happy if I can re enable it on my servers. - Debian and other distributions have already fix this in their systems. http://bugs.proftpd.org/show_bug.cgi?id=4169 https://security-tracker.debian.org/tracker/CVE-2015-3306 + https://www.debian.org/security/2015/dsa-3263 Is there a special reason why this still not fixed on the LTS versions of Ubuntu? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1462311 Title: proftpd mod_copy issue (CVE-2015-3306) To manage notifications about this bug go to: https://bugs.launchpad.net/proftpd-dfsg/+bug/1462311/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1560548] Re: Redundant fontconfig files
Maybe you can make the bindings locale-specific with something like ? Regarding the current config, regardless of if the files are being dropped, I have to say that UKai shouldn't really be in one of sans, serif or mono -- Kai is more like 'cursive' (not 'Comic Sans' -- think of script typefaces like Zapfino or Brush Script.) Such mismatch is partially what causes bug #502610 to look that significant. PS: Personally I often find some Chinese Serifs like SimSun and UMing too thin to match the weights of western serif fonts. The LaTeX community seem to do this better with serif fonts from cwTeX and Fandol. Perhaps Ubuntu can consider using these too? (Be advised, these fonts are not hinted -- they only care about printing...) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1560548 Title: Redundant fontconfig files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fonts-arphic-ukai/+bug/1560548/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1468027] Re: change default CJK fonts to Noto CJK
Not sure. Some fontconfig tracing env vars might be useful for the Skia LegacyCreateTypeface part I guess... * * * In addition to the weight matching problem, the screenshot for Chromium in #113 gives the JP variant instead of TW. Perhaps I should try to get someone to reproduce this in other distros and file a report upstream... Not sure about what the title will be. > Don't Chrome and Chromium care about fontconfig, but do it their own way? Chrome seems to provide some level of per-script font handling[1]. Actually Google Chrome gives a link to an extension called ‘Advanced Font Settings’ (caclkomlalccbpcdllchkeecicepbmbm) in its font menu... [1]: https://developer.chrome.com/extensions/fontSettings Regarding the JP problem, it seems that Google Chrome is trying to do the script recognition itself. This happens on my Windows 10 machine too -- Chinese comments on GitHub and Tweets are all rendered using ‘Inziu Roboto JP’, my default Japanese script font set with ‘Advanced Font Settings’. Webpages with explicit language/script declarations like https://zh.wikipedia.org/zh-tw/ work fine since they don't need any recognition by Chrome (will anyone confirm this on Ubuntu?) It seems that some Chrome font settings can be pre-hacked by editing webkit.webprefs.fonts. The 'Zyyy' (default script) one found in chrome settings is stored in the file 'Preferences' -- perhaps some settings for other scripts can be filled in here too? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1468027 Title: change default CJK fonts to Noto CJK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-seeds/+bug/1468027/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566651] Re: Blurry fonts after update to fontconfig 2.11.1-0ubuntu9
Does force-regenerating font cache using `fc-cache -f` help? The commit message in 3cd573f says: > This may breaks the cache but not bumping in this change sets at this moment. > please be aware if you want to try it and run fc-cache before/after to avoid > the weird thing against it. I didn't list the version-bump commit for cherry-picking. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566651 Title: Blurry fonts after update to fontconfig 2.11.1-0ubuntu9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1566651/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1556457] Re: [FFe] Demilight (OS/2 weight=350) confuses fontconfig
** No longer affects: fontconfig (Arch Linux) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1556457 Title: [FFe] Demilight (OS/2 weight=350) confuses fontconfig To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/1556457/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1556457] Re: [Resolved Upstream] Demilight (OS/2 weight=350) confuses fontconfig
** Description changed: See https://bugs.freedesktop.org/show_bug.cgi?id=81453 and bug 1468027. Fontconfig lacks support for many OpenType/TrueType OS/2 font weight values. This causes a bunch of problems, like mixing up Demilight (weight=350) and Regular (weight=400). Although it's possible to write (dirty?) hacks for deb-packed fonts, this still causes problems for otherwise sourced fonts. - Archlinux: https://bugs.archlinux.org/task/48550 + Archlinux: https://bugs.archlinux.org/task/48550 (fix released) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1556457 Title: [Resolved Upstream] Demilight (OS/2 weight=350) confuses fontconfig To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/1556457/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1468027] Re: change default CJK fonts to Noto CJK
Let me file the fc demi report separately then. A fix is always better than a hack, and with Noto Sans CJK hacked there are still a whole bunch of Notos and other weight-rich fonts. Just realized my PPA pkg is based on 2.11.1-0ubuntu6 instead of current ubuntu8, hmm. Can't see xenial on bzr... Whatever. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1468027 Title: change default CJK fonts to Noto CJK To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/1468027/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1468027] Re: change default CJK fonts to Noto CJK
So updates from fontconfig for those who doesn't want to wait for the bugzilla crawler.. Fontconfig 2.11.1 is ancient, and support for demilight has been added in https://bugs.freedesktop.org/show_bug.cgi?id=81453, which ended up in those oddly-numbered releases like 2.11.91 or so. The current latest release found in https://www.freedesktop.org/software/fontconfig/release/ is 2.11.94. And the wiki page pointing to 2.11.1 was never updated since 2014-03-07. Hmm... It's your decision to decide whether to update fc to such an undocumented version. ** Bug watch added: freedesktop.org Bugzilla #81453 https://bugs.freedesktop.org/show_bug.cgi?id=81453 ** Also affects: fontconfig (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1468027 Title: change default CJK fonts to Noto CJK To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/1468027/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1468027] Re: change default CJK fonts to Noto CJK
gunnarhj: > Want to say, though, that the config file you mentioned in the upstream bug > report doesn't have anything to do with it. It's not in the Ubuntu archive > yet. Umm… The good news is they seen to point to the same problem, and on JeffBai's machine that's almost how the config was written (without language matching, etc.). Anyway that works as a good test case... > + Noto Sans CJK SC Regular Nice workaround. Do you mind testing other weights too? $ LC_CTYPE=zh_CN.UTF-8 fc-match sans-serif:weight=bold -a | head -7 If bold works, you can assume others work too, I think. If you really want to make sure, you can try out all the possible weight values in https://www.freedesktop.org/software/fontconfig/fontconfig-user.html, shown under . -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1468027 Title: change default CJK fonts to Noto CJK To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/1468027/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1556332] [NEW] Playing m4a with gst-launch on Lubuntu Xenial causes stack smashing
Public bug reported: gstreamer0.10-ffmpeg-5ubuntu1~vivid $ gst-launch playbin2 uri=file:///home/wax/sound//.m4a Setting pipeline to PAUSED ... Pipeline is PREROLLING ... *** stack smashing detected ***: /usr/bin/gst-launch-0.10 terminated Aborted (core dumped) ** Affects: gstreamer0.10-ffmpeg (Ubuntu) Importance: Undecided Status: Invalid ** Package changed: ubuntu => gstreamer0.10 (Ubuntu) ** Package changed: gstreamer0.10 (Ubuntu) => gstreamer0.10-ffmpeg (Ubuntu) ** Description changed: + gstreamer0.10-ffmpeg-5ubuntu1~vivid + $ gst-launch playbin2 uri=file:///home/wax/sound//.m4a Setting pipeline to PAUSED ... Pipeline is PREROLLING ... *** stack smashing detected ***: /usr/bin/gst-launch-0.10 terminated Aborted (core dumped) ** Changed in: gstreamer0.10-ffmpeg (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1556332 Title: Playing m4a with gst-launch on Lubuntu Xenial causes stack smashing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10-ffmpeg/+bug/1556332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1468027] Re: change default CJK fonts to Noto CJK
** No longer affects: fontconfig ** Bug watch added: freedesktop.org Bugzilla #94505 https://bugs.freedesktop.org/show_bug.cgi?id=94505 ** Also affects: language-selector via https://bugs.freedesktop.org/show_bug.cgi?id=94505 Importance: Unknown Status: Unknown ** No longer affects: language-selector ** Also affects: fontconfig via https://bugs.freedesktop.org/show_bug.cgi?id=94505 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1468027 Title: change default CJK fonts to Noto CJK To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/1468027/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1468027] Re: change default CJK fonts to Noto CJK
Weights shouldn't be 'specified' at all under normal circumstances (like in AOSC OS). Try matching for something like Sans:weight=regular? It should be good if someone can figure out which weight LibreOffice was asking for… -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1468027 Title: change default CJK fonts to Noto CJK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/1468027/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1000666] Re: Mojibake displaying Unicode Table
Failed to reproduce using w3m version w3m/0.5.3+git20151119 (xenial), thru an SSH link using mintty UTF-8. The line in the header looks interesting though. The actual encoding of the webpage is UTF-8. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1000666 Title: Mojibake displaying Unicode Table To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/w3m/+bug/1000666/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1535214] Re: zh_TW is not set as fallback locale when selecting Hong Kong as location
Assuming this a language-selector problem since this is the only thing to choose language during installation that I can think of so far. https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/language- selector/wily/revision/39 looks revelant, but it actually happened on 2008-03-06 -- almost 8 years ago, and there seems to be nothing about zh_HK before then. Could you please point out when `before' actually refers to? * * * And, well, a +1 on this bug, since some fallback is indeed necessary here -- not only for zh_HK, but also for other smaller zh locales. This tree roughly illustrates the 'relative distance' between locales. zh: Hans: # simp script CN SG Hant: # trad script TW _geo_near_: # you might need a map here HK MO For quite a while zh_HK users have been using zh_TW translations as their main source of fallback text, especially for many translations hosted on GNU TP. I haven't heard from any zh_MO users yet though. Cross-script fallback is not recommended since: a. these chars do look quite different. (A user of one script is often able to recognize the other, but they look too different and can almost be spotted with a glance.) b. the terminology used show significant difference across scripts. See also https://bugzilla.gnome.org/show_bug.cgi?id=757867#c2 on some locale info. ** Bug watch added: GNOME Bug Tracker #757867 https://bugzilla.gnome.org/show_bug.cgi?id=757867 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1535214 Title: zh_TW is not set as fallback locale when selecting Hong Kong as location To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1535214/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1468027] Re: change default CJK fonts to Noto CJK
happyaron: O again, rendering, rendering, rendering. For systems with TT
Bytecode support, be5invis has a release of SHS with his sfdhanautohint
(for CJK) and ttfautohint applied called [Inziu]. Follow the link and
fetch inziu-20\d{10}.
These generally look better on lower ppem sizes (common for loDPI screen
display), and is turned off (just not generating the bytecode) for sizes
>= 25ppem (and for fairly impossible sizes like <=9ppem). Hey this
discussion looks familiar doesn't it…
Oh and these are all TrueType, so expect the same problem (or benefit,
for Qt users) with Kaigen Gothic—you lose some OpenType features.
Generated bytecode also makes the files fat.
[Inziu]:http://code.fosshub.com/Inziu/downloads
Anyway these sharp things will not be considered with Ubuntu's current
hintslight policy. This policy is not quite loDPI optimized either so
you might want to… whatever. WQY looks blurry too, you know. I thought
the WQY files were hintless actually.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1468027
Title:
change default CJK fonts to Noto CJK
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/1468027/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1468027] Re: change default CJK fonts to Noto CJK
My decaying brain… I mean \d{6}. I should just say ‘anything that's not
iosevka’.
* * *
Well the biggest blocker here is actually some application support
things. Qt show poor overall handling of some OpenType features used in
SHS, the most significant being LOCL used in all those Super files. Line
spacing also look weird under both Noto and SHS (SHS has a few releases
to fixes some of the problems under OS X but … some said they break
Plasma 5.)
If compatibility looks like a issue, a (relatively crazy) solution is to
preinstall Kaigen Gothic instead. It's basically a TrueType version with
some features removed (sigh.) If size looks like a problem (it
definitely is), try to wise with the weights to preinstall, and don't
even consider adding bytecode.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1468027
Title:
change default CJK fonts to Noto CJK
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/1468027/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1258778] Re: IBus input candidates not shown in GNOME Fallback session
albertsmuktupavels, at first I thought someone should open a separate bug on GNOME for recording that popup TODO.. Since it's now officially (i.e. by you, a GNOME & Ubuntu Dev) used as the bug that corresponds to this one, I added the remote bug watch. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1258778 Title: IBus input candidates not shown in GNOME Fallback session To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-flashback/+bug/1258778/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
