I'm pretty new on this list so let me quickly introduce myself, my name
is René Ribaud, I live in the
south east of France in the Alps. I work in computer science
(Unix/Linux/storage) for a big computing company.
I have used Fedora for several years and I would like to bring my small
contribution to this project by packaging software.
I would like to package the KanjiStrokeOrder font provide here :
However despite I have read documentation on the Fedora wiki, I still
have some doubts or questions. That's the reason why I'm writing on this
Most of my questions are related to fontconfig.
I have read this : "You should always consider adding fontconfig tuning
to your font packages." and this is the beginning of my problems. :)
So I have written the simple, minimal fontconfig file provided below :
/<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "../fonts.dtd">
And I choose the lowest priority font prefix 69, to not overwrite any
font settings and also because the definition "Fonts with less common
encodings, ending with fonts that provide coverage of exotic unicode
blocks at the expense of drawing quality" seems to be good for this font.
So I wonder :
- If the fontconfig file is fine or need more information inside ?
- If the prefix is the good one and maybe more rules to select it ?
All advises regarding these points will be welcomed.
I also provide the following links, this is not for a review, I will ask
for one later. But it may be interesting for you.
SPEC : http://uggla.free.fr/rpmbuild/SPECS/kanjistrokeorders-fonts.spec
Le mercredi 24 mars 2010 à 21:55 -0400, Jon Stanley a écrit :
> [lots of folks BCC'ed]
> This is an email being sent to all SIG's that are listed on the SIG
> page on the wiki. I'm trying to find the individual that's the
> "leader" of the SIG in order to avoid spamming mailing lists, but
> sometimes, that's what is necessary.
> I'm writing on behalf of the Fedora Engineering Service, a new group
> within Fedora that acts on items submitted by FESCo that general
> volunteers are not likely to accomplish because either they are more
> administrative in nature, or there is a general disinterest in doing
> it, generally because it's seen as "boring". The task that I am now
> engaged in falls within that category :).
> As FESCo has responsibility for SIG oversight in Fedora, I'm supposed
> to figure out where each SIG stands in terms of their activities in
> Fedora. Specifically, we have a few questions that we'd like answered
> by each SIG leader:
> 1) Is your SIG still active? (if no, skip the remainder of the
> questions, unless you feel that it could be active again, if only for
> not having resources, etc)
Yes it is still active though I'm the main person animating it and I've
not done a good job of it lately due to lack of time
> 2) Would your SIG be so kind as to provide monthly status reports to
> either FESCo or the 'devel(a)lists.fedoraproject.org' mailing list?
> Think of this not as a bureaucratic measure being imposed on you, but
> more as what I call a "force multiplier" - a way to bring to the
> forefront of the larger Fedora community what your SIG is doing and
> why they might want to get involved in it.
I've tried in the past to post such reports on the devel list but have
realized that they take too much work to be done monthly (I spent
several weeks preparing them, which is not efficient given the low
number of active contributors to the SIG).
Therefore I've written an audit script (repo-font-audit in
fontpackages-tools) that collects 80% of the info I used to collect
manually, is more thorough, and can be run at any time by anyone to
check the fonts status in Fedora.
> 3) Are there any resources that other teams in Fedora could provide
> (design work for something, marketing outreach, documentation people,
> IRC channel, mailing list - whatever you can think of, really) that
> would be beneficial to your SIG?
The art team has been kind enough to publicize the fonts they wanted
packaged. This has been invaluable (even though I think Mairin has been
disappointed in the number of fonts that got packaged quickly) and I
hope this effort will be sustained in the long run.
It would be invaluable if someone took repo-font-audit and figured how
to integrate its tests in autoQA. It won't happen before a long time
otherwise, which is a pitty.
It would be nice if someone plumbed repo-font-audit to a cron
server-side to provide the monthly reports you asked for (I'm not always
available to run it at the right date, or my rawhide system may be too
broken to run it, etc)
Many fonts already existed in Fedora as part of apps before the fonts
sig existed. Unlike fonts packaged by the SIG, they often violate all
sorts of packaging guidelines. We'd like each packager and SIG to review
its existing packages that include fonts and clean up their packaging
(TEX is a huge sore). We'd like QA to get involved in motivating those
packagers to clean up their packages. Had it involved itself when the
fonts packaging guidelines were clarified last year (as we tried to
request through a Fedora feature) we could look forward instead of
dragging those old problems still.
We do not have anyone interested in core fonts in the SIG but people
assume we're the one that need to clean up this mess. Someone is needed
to take charge of those, it's a never ending source of friction
We do not have enough feedback from local teams. It's awfully hard to
figure if a font is good or not for a script you're not a native user
of. The i18n team has good engineering resources but we need more local
involvement (ambassadors, l10n) to report breakage in fonts (not just
"this font is bad" but "this font is bad because of this bit in this
glyph", so it is not a 15 min feedback task)
The main font libraries (freetype, fontconfig, pango...) in Fedora are
in a pretty good shape but many apps (even art/design/office oriented
apps) do not use them properly and then users blame the libs of the
fonts. We need more people to fix font problems application-side, and we
need people to document how apps are supposed to use fonts, because it
turns out many application authors are only dimly aware of OpenType
specifics and misuse fonts because they think the reality is simpler
than it is (ascii fonts, no ligatures, only n,b,i,bi styles). A lot of
bug reporters just dump their problems on the fonts sig and assume we'll
relay wherever's appropriate — but we're too short-handed to do it and
many times the fix is outside fonts sig packages.
We need more people. Any help to recruit them is welcome :)
"Windows has decided that fonts with 'name' tables bigger than 5K are
insecure and will refuse to load them. Don't ask me why they believe this.
This font has a name table which is 6948 bytes and is bigger than this
.... MicroSoft recently (2009) released a security patch in which they
decided that font's whose 'name' table was bigger than 5K were insecure.
Personally I cannot fathom their logic, but that's OK, I usually can't.
Unfortunately many licenses *are* bigger than 5K, the OFL is for one, so it
is now "better" to include a link to a license website rather than the full
text of the license -- at least it is if you want your font to work on
Most of the fonts has license included inside fonts itself.
One of the recurrent questions about open/libre font creation is where
to get some funding. For people not aware of it:
1. The Mozilla Fundation has indicated in the past it is ready to
sponsor initiatives to improve open/libre fonts (and indeed the OFLB has
benefited from some funds).
2. The Internet Society has a grants program that includes this year «
Enabling Access for Under-served Communities (including people that use
non-Latin language scripts) », up to 10 000 $ per project
Both of them are primarily interested in fonts as an access enabler. So
as I read it they are unlikely to sponsor the creation of new fonts from
scratch (because they are unlikely to get the level of distribution that
would have an effect on access). However, a proposal to extend of fix
non-latin support in one of the existing and widely-used open/libre
fonts, is likely to meet the funding requirements.
Added fonts list in Cc.
>>>>> On Wed, 10 Mar 2010 10:42:45 -0500,
>>>>> Qianqian Fang <fangqq(a)gmail.com> wrote:
> sorry, recent with gmail account.
> On 03/10/2010 02:35 AM, Peng Wu wrote:
>> Thanks for notifying me this, I missed the hintings for Latin glyphs.
>> After this discussion, I will post changed font conf files on bugzilla for review.
>> I will try to use the same technique in UMing confs(maybe will be switched to UKai):
>> <test name="lang" compare="contains">
>> <test name="family">
>> <edit name="family" mode="prepend" binding="strong">
>> <string>Bitstream Vera Sans</string>
>> <string>DejaVu Sans</string>
>> <string>WenQuanYi ZenHei</string>
> well, syntax is one thing, the more important is which fontconfig
> file, and what prefix number will you use.
> In the past, this was done by font package itself in Fedora: if a
> font wants to be the default, it simply sets a prefer list in its
> own fontconfig file; if multiple maintainers want their fonts
> to be the default, they will have to compete the prefix number:
> the smaller number wins (unless the later ones use prepend_first).
> To avoid this mess, I had proposed a set of cjk specific config
> files with clean and centralized settings, you can see the
> whole proposal here:
The outcome of both solutions may be same unless both
solution is mixed up. either of solutions has advantages and
The centralized solution is simple right. it works enough
for simple requirements like:
* you are a kind of SIers who need to provide only the
solution of the default sets of fonts for customers,
because you don't need to think about a lot of
preferences which may conflicts each other.
* you don't care of multilingualization on the system or
just need to care of single/few language(s), because the
<prefer> list is a global configuration and can't be
applied for the specific languages. this often prevents
the expected behaviour if the script could be used for
other languages too but want to use the different fonts
* you always mandate your customers/users updating
65-nonlatin.conf to use the extra fonts by default on the
system. which isn't in the list or is lower priority in
Any of the above issues are important for distributors since
it's quite hard to figure out all of requirements and
preferences. it would be really nice every fonts packages
potentially can be used without any additional
modifications. activating the fonts with the installation
would be ideal --for instance, the script to bring the input
methods up at the startup time was centralized in xinit
package in the past and hardcoded there. we had frustrated
when we want to make any changes. now it leaves to the IM
packages. users can use anything they want without modifying
the centralized thing.
Also you are trying to explain the mess of the separate
rules idea though, only difference between both are where it
happens --one is on the filesystem, one is in the file. both
should potentially has same issue if one who has different
thoughts and preferences. though our idea is more complex
than yours right since it could be broken with the rule from
another package. this concern would be most likely when the
packagers makes any changes selfishly. however that can be
avoided or fixed. that's why we have the packaging policy
and guidelines to not mess up and explain what's a must to
do and required. thinking about things that not following
that way makes no sense here. If there are any issues in
the guidelines, it would be good to point that out,
explaining the detailed case and improve it for the future
> but briefly, what you need to do is to update 65-nonlatin, and
> add two cjk specific config files: 65-language-zh.conf and
> 65-language-ja.conf, see
> unfortunately, Fedora people seemed not to be very keen to this solution,
> for some reasons, and the proposal is currently stalled. Despite that,
> I got response from Arne, the CJK fontconfig maintainer for Ubuntu
> that he is interested to this:
> so, I still highly suggest you considering this cleaner solution if you
> want to wire up the CJK font orders. Of course, you have to
> communicate with Jens and Akira more on this matter.
> just a side note, use binding=strong is generally not preferred.
> use smaller prefix number if you want to overwrite other rules.
I agreed with this part. Peng, please have a look at
first and if you need anything else rules not at that page,
please bring that up on the fonts list before changing the
Currently we are considering to improve Traditional Chinese and Simplified Chinese support. And part of these changes is some changes on fonts. We create a bug report to notify the WenQuanYi font upstream(Qianqian Fang), and he gives some other suggestions. (See also: https://bugzilla.redhat.com/show_bug.cgi?id=568613)
As suggested by Jens Petersen, we did a survey on #fedora-zh channel and fedora-cn goolge groups. (See here: http://groups.google.com/group/fedora-cn/browse_thread/thread/4a3595996ef..., in Chinese.)
Here are the summary of the discussion:
Result: most users have agreed the following changes:
In Chinese locale, "WenQuanYi ZenHei" font will be default Sans font, "UKai" font will be default Serif fonts, "WenQuanYi ZenHei Mono" will be default Monospace.
According to some explanation by kaio, some Traditional characters have different styles between TC style fonts and SC style fonts. If user choose sans or serif for desktop font, it will show the text with the consistent writing style which he wants after applying this change.(See also: http://tetralet.myweb.hinet.net/blog/Font_Compare.png)
Please review the proposal.