Description of problem: Original problem is that xfig is not finding fonts it needs. This is caused by missing fonts.scale and fonts.dir in {_datadir}/fonts/default/Type1 Which should be created in %post (in urw-fonts package): %post { umask 133 mkfontscale %{fontdir} || : `which mkfontdir` %{fontdir} || : fc-cache %{_datadir}/fonts } &> /dev/null || : However mkfontscale and mkfontdir (why the funny `which mkfontdir` thing, btw?) is in the xorg-x11-font-utils package which urw-fonts have no requires line to. Solution: add xorg-x11-font-utils to requires like this: Requires(post): fontconfig xorg-x11-font-utils I guess this problem in present in Fedora 7 too. Thanks!
Please do not suggest solutions contrary to official fonts packaging policy objectives http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy#no-handler-deps Find a solution that does not require adding deps all over the place, like it's already the case for the fontconfig part http://fedoraproject.org/wiki/PackagingDrafts/FontsSpecTemplate
(In reply to comment #1) > Please do not suggest solutions contrary to official fonts packaging policy > objectives Please realise this is not ttf or otf fonts. If you want to port xfig to fontconfig, be my guest.
This is madness, but ok: So we need a cron job (package) which loops over all fonts dir and creates fonts.dir and fonts.scale files. Nice. Much better than the old system.
This has been discussed already, see: https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01730.html The most simple solution is to just ship pregenerated fonts.dir and fonts.scale files. This will work as long as the dir in which the fonts reside is not shared with other packages. I guess its time to add this to the font guidelines. Alternatively we could fix the font guidelines to drop the bogus demand to not depend upon xorg-x11-font-utils, xorg-x11-font-utils is very small, and has no special requires. And Nicolas, can we please get some more care for core fonts in the font sig, or otherwise rename it to the fontconfig sig? core fonts are not going to go away, they are used by Xt and derived toolkits like Xaw, and motif, that adds up to a lot of apps we are talking about.
(In reply to comment #4) > Alternatively we could fix the font guidelines to drop the bogus demand This is not a bogus demand and works fine for other font backends, and there's no reason it can not work fine for core fonts. > And Nicolas, can we please get some more care for core fonts in the font sig, Core fonts will get as much care in the SIG as core fonts users contribute. It's a wiki, write autoritative core font scriptlets or guidelines I've said many times I would welcome them. What I refuse to do is to do this work in the stead of core font users. I've paid the "can not find font fixed" price like everyone in the distro for years, it's time for core font users to start taking care of themselves. > core fonts are not going to go away, > they are used by Xt and derived toolkits like Xaw, and motif, that adds up to > a lot of apps we are talking about. Then surely there is at least one core font user willing to expend the time to think about and write core fonts packaging guidelines.
If fonts guys refuse to add xorg-x11-font-utils we could add Requires(post): xorg-x11-font-utils Requires: urw-fonts # add more fonts pkgs if needed and run mkfontscale and mkfontdir in %post section of xfig-common.
Terje, there are many possible technical solutions, someone just needs to take responsibility for the core fonts ecosystem, write coherent rules, and get every package that uses core fonts to respect those rules
Yes, I took the time to read the thread from comment #4, shipping correct fonts.* files in the first place make most sense.
(In reply to comment #5) > (In reply to comment #4) > > > Alternatively we could fix the font guidelines to drop the bogus demand > > This is not a bogus demand and works fine for other font backends, and there's > no reason it can not work fine for core fonts. > True, it might very well be made to work for core fonts, but, see below ... > > And Nicolas, can we please get some more care for core fonts in the font sig, > > Core fonts will get as much care in the SIG as core fonts users contribute. It's > a wiki, write autoritative core font scriptlets or guidelines I've said many > times I would welcome them. > > What I refuse to do is to do this work in the stead of core font users. I've > paid the "can not find font fixed" price like everyone in the distro for years, > it's time for core font users to start taking care of themselves. > The problem is not that you are refusing to work on core font Guidelines, the problem is that you are actually meddling with Core fonts existing practices in such a way that core fonts break. If you don't want to touch core fonts, then don't touch them, including not touching the requires needed for the current scriplets! Here is what the font sig has done: * Create a guildeline that font scriptlets may not have requires Result: * Poof core fonts are broken Here is what the font sig should have done: * Create guidelines for core font scriptlets so that the requires are no longer needed, yet things still work. * Create a guideline saying that core font scriptlet requires are no longer allowed, and that instead the new scriplets should be used. Result: * Things stay working Or alternatively the font sig could have done this: * Don't make any changes to core fonts as they are fragile, and this means keeping the requires for mkfontdir / mkfontscale Result: * Things stay working You (the font sig) have broken things, so now YOU get to fix it. Its really that simple, everything else is just white noise. If you don't want to fix ti, then undo the breaking. Breaking things and then saying yeah we broke it, but we don't care about it so its not our problem, is not acceptable <period>. > > core fonts are not going to go away, > > they are used by Xt and derived toolkits like Xaw, and motif, that adds up to > > a lot of apps we are talking about. > > Then surely there is at least one core font user willing to expend the time to > think about and write core fonts packaging guidelines. > Perhaps, but right now the font sig is doing things backwards, YOU are actively causing breakage, while you should have waited / worked in guidelines instead of just breaking things. YOU are causing regressions, stop doing that please.
(In reply to comment #9) > (In reply to comment #5) > > (In reply to comment #4) > > > And Nicolas, can we please get some more care for core fonts in the font sig, > > > > Core fonts will get as much care in the SIG as core fonts users contribute. It's > > a wiki, write autoritative core font scriptlets or guidelines I've said many > > times I would welcome them. > > > > What I refuse to do is to do this work in the stead of core font users. I've > > paid the "can not find font fixed" price like everyone in the distro for years, > > it's time for core font users to start taking care of themselves. > > > > The problem is not that you are refusing to work on core font Guidelines, the > problem is that you are actually meddling with Core fonts existing practices in > such a way that core fonts break. Please look at changelogs dates, this particular package (and all the broken core font packages we have right now) was modified before I even launched the Font SIG idea. I didn't break anything. I didn't touch this package. It would be broken the same way if I hadn't done any font work. Now people find out core fonts are broken, I only ask they find clean solutions that do not clash with what we've done for other font systems, and document them so we don't hit the same problems in 20 different packages. Core font users are used to the comfortable position where someone else fixes their problems for them. Big news: core font system is not critical enough anymore for this to happen. Stop complaining about the SIG the SIG didn't break anything, core fonts basically broke because no one was caring enough anymore to write good guidelines and check they actually work. The fix is to actually step up to write the guidelines, not rant about the SIG in bugs.
in my opinion, it isn't a good idea to ship pregenerated fonts.dir and fonts.scale in urw-fonts. Adding requires on xorg-x11-font-utils is the clean solution for me.
the problem is only affected in F8 and new
(In reply to comment #11) > in my opinion, it isn't a good idea to ship pregenerated fonts.dir and > fonts.scale in urw-fonts. Adding requires on xorg-x11-font-utils is the clean > solution for me. Agreed, lets do that then (as many core fonts packages still do) and close this bug. I think since many people will have this problem without knowing it this warrants an F-8 update (besides fixing this in devel). As for this being against the new fonts guidelines, the new guidelines are broken in that they do not offer a solution to the problem this creates, so I say ignore them until this bug in the guidelines gets fixed.
(In reply to comment #13) > As for this being against the new fonts guidelines, the new guidelines are > broken in that they do not offer a solution to the problem this creates, The new guidelines are not broken. They don't offer a solution but don't prevent every solution either. You know that perfectly well. I only ask you to respect the work of other project members and try to fit in. If you prefer to knowingly make quick and dirty antisocial choices rather than: 1. think 10 min 2. do the missing documentation work (on a subsystem you've just claimed is highly critical for you) That's pretty sad, and will end up in ugly clashes. And I don't even ask an apology for your wild claims I broke this package, or all the other core fonts packages that passed all F8 test releases without one core fonts user bothering to test them and report problems.
(In reply to comment #14) > (In reply to comment #13) > > > As for this being against the new fonts guidelines, the new guidelines are > > broken in that they do not offer a solution to the problem this creates, > > The new guidelines are not broken. They don't offer a solution but don't prevent > every solution either. You know that perfectly well. > By requiring the removal of Requires on mkfontdir and mkfontscale and not giving a solution for the problems this creates, they are causing this breakage, or in this case since appearantly the Requires were removed before the guidelines they are stopping this problem from getting fixed. > I only ask you to respect the work of other project members and try to fit in. > If you prefer to knowingly make quick and dirty antisocial choices rather than: > 1. think 10 min > 2. do the missing documentation work (on a subsystem you've just claimed is > highly critical for you) > That's pretty sad, and will end up in ugly clashes. > Whats antisocial about adding a single innocent requires? Why must font packages not have this requires? If not having those requires is so important to some, isn't it up to those some to come up with fixes for the problems this creates? > And I don't even ask an apology for your wild claims I broke this package, or > all the other core fonts packages that passed all F8 test releases without one > core fonts user bothering to test them and report problems. No problems were reported because most test release users update from previous releases thus avoiding the problem, just because it didn't get reported earlier doesn't mean its not a problem. And I do apology, as I've just re-read the font guidelines as written here: http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/Policy And I was wrong, they only disallow Requires on mkfontdir / mkfontscale for "non-legacy format (TTF or OTF)" fonts, so they do not apply to urw-fonts, nor to any fonts installed by default as core fonts. So the solution for this is really simple, just readd the Requires(post): mkfontdir and mkfontscale, and all is well. Than can you do that please, and preferably make this an F-8 update as well? Thanks!
it's already built in F8-update tree and will be pushed today or tomorrow
> it's already built in F8-update tree and will be pushed today or tomorrow Thanks Than!
urw-fonts-2.4-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.