Le Jeu 24 avril 2008 07:32, Peter Lemenkov a écrit :
> Hello All!
> See screenshot:
I've seen this installing/updating font packages while firefox was
running. Restarting firefox always fixed the problem. There is a bug
somewhere in the font stack firefox uses which makes it loose its
little mind when font files change under it. (if anyone had a bug
pointer it'd be great)
When looking over the LiveCD manifest, and where space is going, I
can't help but notice that a lot of it goes to fonts. Here's the
full list, AFAICT. The number to the left is the size of the package.
I think a good chunk of this could be pruned.
1) Fonts not used by any fontconfig app. I don't think we
ship any apps that aren't fontconfig users on the livecd (and
if we do, we shouldn't...)
2) Bitmap fonts, which almost certainly won't be pulled in
by fontconfig by default.
3) Everything else. These are probably OK. :)
Le samedi 19 avril 2008 à 11:31 +0300, Oron Peled a écrit :
> [cross-posting to an Israeli Group of Linux Users.
> IGLU readers, please read and send me your feedback.
> A concrete information (specific apps, toolkits, specific
> characters/nikud) would help us form a valid opinion]
> On Saturday, 19 בApril 2008, Nicolas Mailhot wrote:
> > Le vendredi 18 avril 2008 à 15:57 -0400, Bill Nottingham a écrit :
> > > When looking over the LiveCD manifest, and where space is going, I
> > > can't help but notice that a lot of it goes to fonts. Here's the
> > > full list, AFAICT. The number to the left is the size of the package.
> > > I think a good chunk of this could be pruned.
> > My advice would be:
> > ...
> > 4. drop culmus — DejaVu full includes Hebrew no one complained of during
> > the F9 cycle, so no need to keep a separate Hebrew font on a
> > space-constrained media
> If DejaVu provides "good-enough" substitute for space limited media,
> than it may be OK.
Well, DejaVu certainly does not aim just at "good enough". Please report
any problem with it upstream. Even if Culmus stays in Fedora users will
mostly see DejaVu since it's the default font set (not just in Fedora
BTW). So if your script is included in DejaVu you really want to work
with DejaVu upstream to get it good.
Anyway that highlights a problem with fonts: users are highly sensitive
to font changes, and fonts change slowly. So l10n groups *must* test the
Fedora font selection very early in a cycle. Any problem spotted after
what used to be called Test2 is unlikely to be fixed in time for the
More local involvement in font packaging would help of course.
Le vendredi 18 avril 2008 à 18:44 -0400, Warren Togami a écrit :
> I noticed the description of the VLGothic fonts package.
> VLGothic provides Japanese TrueType fonts from the Vine Linux project.
> Most of the glyphs are taken from the M+ and Sazanami Gothic fonts,
> but some have also been improved by the project.
> Does this mean that VLGothic is a superset of Sazanami?
> (Could these be considered redundant fonts taking up space
> unnecessarily? I'm guessing not, but just checking to be sure.)
VLGothic is the new japanese default. That means every other japanese
font could be dropped on a space-constrained media IMHO. If the other
variants have not been dropped from Fedora Everything they're probably
useful to someone.
Le samedi 19 avril 2008 à 00:36 +0200, Sebastian Vahl a écrit :
> I've got a similar question here for the KDE live images. At the moment
> our fonts list is:
At first glance you could use pretty much the same advice as the live
spin, except you've already followed some of it, and you have support
for some scripts the main live spin is missing (which is good, if you
have the space). For example : tibetan & ethiopic (abyssinica).
If you really wanted to save space, you could drop the urw & ghoscript
fonts, but I suspect you may have some packages depending on them
explicitely. They don't add coverage, and they're not really good screen
font, but they do provide some standard font metrics (is it worth some
live cd space?)
Le samedi 19 avril 2008 à 02:59 +0530, Rahul Sundaram a écrit :
> Nicolas Mailhot wrote:
> > 6. Have the Indic l10n group sort the huge number of indic fonts,
> > keeping only one package per script (sarai, lohit, smc, samyak)
> Lohit is what we prefer by default for Indic. Everything else can be
> deemed optional.
Since they're all broken up by scripts now you probably want to be more
specific, unless lohit provides every needed indic script and none of
the others is necessary for coverage.
Le dimanche 13 avril 2008 à 20:42 +0100, Richard Hughes a écrit :
> On Sun, 2008-04-13 at 21:09 +0200, Nicolas Mailhot wrote:
> > Le dimanche 13 avril 2008 à 19:39 +0100, Richard Hughes a écrit :
> > > On Sun, 2008-04-13 at 14:17 +0200, Nicolas Mailhot wrote:
> > > > — help users install the right fonts on their system:
> > > > — when a user encounters some script (in its browser, office
> > > > suite, etc) the system can not render due to lack of fonts the
> > > > application used could propose installing the needed font packages
> > > > (probably needs work with Behdad to write an helper that auto-adds the
> > > > needed Provides to font packages at build time)
> > >
> > > Sure, we can install them trivially. See
> > > http://hughsient.livejournal.com/55964.html
> > It's not trivial because current packages do not have the necessary
> > metadata. And the install-fonts-by-style is yet another thing. But since
> > this metadata would be pretty useless for humans and only makes sense in
> > a packagekit-like context, you have a chicken and egg problem.
> Well, yes and no. Bastien wrote a script to auto-add the codec metadata
> as provides in the spec file, so now we can install the right codec by
> querying the provides. Can we not do the same thing with font-styles?
> It's three lines of code to install a package from a provides using
That's what I was proposing. But I suspect a good auto-provider would be
non-trivial, which is why having Behdad in the boat would be good.
Le dimanche 13 avril 2008 à 19:39 +0100, Richard Hughes a écrit :
> On Sun, 2008-04-13 at 14:17 +0200, Nicolas Mailhot wrote:
> > — help users install the right fonts on their system:
> > — when a user encounters some script (in its browser, office
> > suite, etc) the system can not render due to lack of fonts the
> > application used could propose installing the needed font packages
> > (probably needs work with Behdad to write an helper that auto-adds the
> > needed Provides to font packages at build time)
> Sure, we can install them trivially. See
It's not trivial because current packages do not have the necessary
metadata. And the install-fonts-by-style is yet another thing. But since
this metadata would be pretty useless for humans and only makes sense in
a packagekit-like context, you have a chicken and egg problem.
> > This is something that would help a huge number of users, much more than
> > codec plugins ever will. It would probably justify the whole packagekit
> > infrastructure alone.
> Okay, lets make this happen. Could you join the packagekit mailing list
> and we'll discuss there how it can be done. I think it's perfectly in
> the scope of packagekit, although we don't want to re-implement this in
> every application that wants to use pango.
Actually, it's every application that uses fontconfig (Behdad is also
Fedora's fontconfig man). Which is a huge application base, so you'd
need a big generic part and a small application-specific glue.
> If you cc Behdad we can all
> talk on the same hymn sheet.
Le Jeu 10 avril 2008 05:05, Erdal Ronahi a écrit :
> Hi all,
> Everyone seems to forget the Fedora Kurd users, but anyway, I'll try
> I'm not forgetting them, I just don't know any. The Kurdish Linux
> is pretty much an Ubuntu Community as far as I am aware.
If you have any user of CentOS, RHEL or OLPC they all reuse Fedora
>> again. We have very similar packaging resources than Debian (only
>> better :p) including:
> Is there any chance that packaging for one distribution (Fedora or
> Debian) will spare me packaging it for the other?
None at all, unfortunately (well everyone tends to copy what's in
RHEL, but that's no decent sharing). Deb-based distributions with copy
debs of other distributions, rpm-based distributions will copy rpms of
other distributions, but you still need to make sure there is one of
both to have correct user coverage.
However, while the packaging steps are a little different, you'll be
asked pretty much the same things Debian and Fedora side.
> I remember packaging a dictionary
> years ago (for Debian) and found it difficult.
I've always considered rpm friendlier on the packager side, but I'm
> Later I was happy to see that
> somebody had made a RPM from it without contribution from me.
> Is something similar possible for fonts?
You can always hope, but there is no guaranty that it will happen soon.