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
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
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
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
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
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.
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
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
** 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
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
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
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
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...
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
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
** 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
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
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
** 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
** 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
** 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
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
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
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
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
> 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
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
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)
> 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
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)
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
31 matches
Mail list logo
