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
it's crunch time for f13, and our kde live images have grown a bit over
the past month due mostly to incremental growth of dependencies. So,
the kde-sig in the unfortunate position of working to trim space to make
it cd-sized again. We've historically made no qualms about admitting
that the kde live spin is (largely) english only.
One option we're considering including only wqy-microhei-fonts (a
compact font with apparently fairly good coverage) and trimming all
other CJK fonts. We estimate this will go a long way to help our size
Would doing something like this be agreeable? Any other comments or advice?
Some time ago, I took over two font packages as they were important to
the fedora-olpc project and their original maintainer was orphaning
The first one has been in need of some love for quite some time:
nafees-web-naskh-fonts. A bug has been reported more than a year ago,
and until now I have failed to fix it properly. This is partly due to
my lack of knowledge about fonts, but mostly because of my lack of
time to acquire that knowledge.
Also, very recently, a bug has been opened against
sil-abyssinica-fonts, and I fear the same is going to happen: it
shouldn't be too hard to fix for someone who knows how to do it, but
I'd need some time to learn this stuff and I'm likely not to have the
time to commit to it, resulting in a package of poor quality.
I realize I've been a crappy maintainer for these packages, and I'm
confident they would be in much better hands if I orphaned them. Would
someone be interested in taking over them?
Here are the open bugs against those two:
If no one is willing to maintain them, even some help with fixing
those two issues would be greatly apreciated. I won't orphan them if
no one steps up as they are required for displaying some languages
which seem to be important for OLPC, but I hope a better maintainer
I've been looking at packaging Cathy Davies' Chemist fonts, as requested
Rather than start from a version on one of the free font sites, I thought
I'd go back to the original source. Nice idea, were it not for the fact
that Cathy only ever issued this in Mac-specific StuffIt format, for which
no free decoders are available. Fortunately, the non-free expander is
quite cheap, so I now know that the original source for these fonts
* 3 Type 1 fonts - "Chemist", "Chemist Rough" and "Chemist Periodic"
* associated FOND resources, containing kerning information
These fonts are released to the public domain, but the README requests
that all three fonts are distributed together, which the conversions on
free font sites are clearly not doing.
In order to make these packagable while respecting the README, I am
proposing to release a new archive (ZIP, say) of the original SIT file,
containing OTF conversions of all three fonts, plus the original README,
and possibly the original Type 1s and FONDs, so the conversion could be
improved in future if anyone wanted to.
Each of the fonts is a single variant of a separate family which, by my
reading of Fedora's font packaging rules, means that I should produce
three subpackages from this single source.
Would it be acceptable to produce a single binary RPM from this single
source, given that there are only three fonts in total? I really can't
imagine why anyone who wanted to install one of these fonts wouldn't want
to have all three.
I'd propose not using compare="contains" as far as possible,
especially must not when scripts are unififed/shared in
Here is an example that messed up with it:
$ rpm -q vlgothic-fonts
$ FC_DEBUG=4 fc-match sans:lang=zh-cn
FcConfigSubstitute Pattern has 2 elts (size 16)
FcConfigSubstitute test pattern any lang Contains "ja"
FcConfigSubstitute test pattern any family Equal
pattern any lang Contains "ja"
pattern any family Equal "sans-serif"
Edit family Prepend "VL Gothic";
So in this case fontconfig says "zh-cn" contains "ja"
according to the orth file.
This may depends on languages. it may works in some case,
but not in some case like the above. that would be good
however to get rid of it from the config file until
fontconfig gets a fix of ll v.s. ll-cc issue.
We currently plan to improve Chinese fonts on Fedora 13. Last time we post a mail on fonts and i18n mailing list, as fangqq proposed a suggestion on this. But after collecting various feedbacks from users, at fedora-i18n meeting, a new proposal is created to replace the previous one. And after recollect these feedbacks, it seems the new proposal is accepted by most users.(Discussion thread in Chinese:http://groups.google.com/group/fedora-cn/browse_thread/thread/617...)
Please review this new proposal, thanks.
The goal of this new proposal is to let Simpilified Chinese (SC) and Traditional Chinese (TC) users choose different fonts. SC users choose SC writing style fonts, while TC users choose TC writing style fonts. some Chinese characters with same unicode code point is written with different style in SC and TC. See: http://tetralet.myweb.hinet.net/blog/Font_Compare.png
To follow the current font policy on Fedora, we consider a new fonts conf for Chinese users in /etc/fonts/conf.d/, as below:
1. When use Simplified Chinese (SC for brief) locale to login Fedora gdm, all default desktop fonts will use WenQuanYi;
2. When use Traditional Chinese (TC for brief) locale to login Fedora gdm, all default desktop fonts will use UMing.
For more details and some other info please read on http://pwu.fedorapeople.org/fonts-conf/README.en and http://pwu.fedorapeople.org/fonts-conf.
Needed Changes for this proposal:
For UMing/UKai, I removed the following fontconfig confs to avoid conflicts with other confs and do some clean up on this: 35-ttf-arphic-ukai-aliases.conf 35-ttf-arphic-uming-aliases.conf 41-ttf-arphic-ukai.conf 41-ttf-arphic-uming.conf 75-ttf-arphic-ukai-select.conf are removed.
and a updated version of 64-ttf-arphic-uming.conf (from http://pwu.fedorapeople.org/fonts-conf/64-ttf-arphic-uming.conf).
For wqy-zenhei, some clean up is done on 44-wqy-zenhei.conf (from http://pwu.fedorapeople.org/fonts-conf/44-wqy-zenhei.conf).
And 65-wqy-zenhei.conf is renamed to 64-wqy-zenhei.conf, in order to override 65-nonlatin.conf. The new version is from http://pwu.fedorapeople.org/fonts-conf/64-wqy-zenhei.conf.
For some unknown reason, the fc-match can't give correct results. But it seems gnome/firefox can choose the right fonts, actually I checked it with :
PS:Please reply to both fedora-fonts and fedora-i18n mailing list.
Le Mer 14 avril 2010 16:40, Jaroslav Reznik a écrit :
> It's a little more complicated - it's not only one particular font application
> depends but this happens with custom installation. Looks like in this case it
> leads to system that does not have any fonts installed at all (as it's handled
> by comps group and probably not through RPM deps resolving). So the question
> is - how to assure that the system has at least one usable font (with custom
Really, it's the same this as with other default comps groups. Dependencies
are not explicit. If you write a custom kickstart that does not include the
default groups, apps will fail. There is nothing inside the packages to make
sure you install every bit in default groups. If you create a custom
configuration that do not include them (or part of them), you have to be ready
I suppose we could rename @fonts to @base-fonts to make the point clear to
people writing kickstart files (they do not complain when they remove base-x
and things go south, but they complain about @fonts), but that would not be so
great for other users.
Another solution would have the tools that generate kickstarts to add a
comment at the start of the file that states the default groups the distro has
been tested with.
Hi font guys,
I would like to know, which package takes care of font dependencies for
graphical applications? For example system-config utilities. They need
_some_ font package, but direct dependency on such _some_ font package
is not good. There should be some lib package to solve this.
There was a bug  saying there's no font. It was fixed by adding
direct dependency to bitmap-fonts package.
But now there is another bug  saying it shouldn't directly depend on
So, is there any package which can solve this dependency problem?
Please keep me and jreznik in CC.