This is an eclass for easier font installation. A part of this file borrows the source code of '/etc/init.d/xfs(x11-base/xfree)'.
Created attachment 7236 [details] font.eclass
The checking /etc/X11/fs/config is not going to work for new fonts that do not install in known locations. Should be able to add the new font dir if not in /etc/X11/fs/config for update ...
Created attachment 12570 [details] font.eclass fixed.
Created attachment 16858 [details] font.eclass
Created attachment 16859 [details] mikachan-font-8.9-r1.ebuild (sample) this is sample ebuild that inherits font.eclass.
I think it is better to create fonts.scale and fonts.dir in src_compile() section so that Portage will automatically remove them when unmerge. We better define not only FONTPATH but also TTFONTPATH, where FONTPATH=/usr/share/fonts/${PN} TTFONTPATH=/usr/share/fonts/ttf/.../${PN} and do mkfontdir to ${D}${FONTPATH} and mkfontscale to ${D}${TTFONTPATH} (and possibly fc-cache). Also I think it would be better to define a function to add bdf, pcf and ttf files automatically. The idea looks like font_install_bdf() { insinto ${FONTPATH} find ${S} -name '*.bdf' | xargs doins } font_install_pcf() { insinto ${FONTPATH} find ${S} -name '*.pcf' -o -name '*.pcf.gz' | xargs doins for f in ${D}${FONTPATH}/*.pcf ; do gzip -9 $f done mkfontdir ${D}${FONTPATH} } font_install_ttf() { insinto ${TTFONTPATH} find ${S} -name '*.ttf' | xargs doins mkfontscale ${D}${TTFONTDIR} fc-cache ${D}${TTFONTDIR} } font_src_install() { [ -n ${FONTPATH} ] && font_install_pcf # we usually don't need BDF [ -n ${TTFONTPATH} ] && font_install_ttf dodoc ${DOCS} } Provided these functions are in font.eclass, all you need is define FONTPATH and/or TTFONTPATH, DOCS and src_compile() section. Just a question to matsuu, why don't you put fontdir_config() into font_pkg_postinst() and font_pkg_postrm() and remove pkg_postinst()/ pkg_postrm() from your sample ebuild?
Created attachment 20837 [details] revised font.eclass
I noticed that fonts are not always installed to its own directory so that we cannot generate fonts.dir inside src_install. I just moved existency check of executables into pkg_setup() and added efontinstall() to automate font installation. btw, what do y'all think about creating font herd to maintain packages in media-fonts? fonts are not always used with xfree but also with terminal emulaters such as jfbterm and iterm, so xfree isn't appropriate IMHO (cjk covers only half of the packages in media-fonts).
I was just debating creation of a fonts herd or having fonts people within the xfree herd. While all fonts people may not care about the rest of xfree, all xfree people do need to know what's going on with fonts IMO. Maybe this means xfree herd members should just be added to the font herd, which will also have the fonts-only people. The easy way to do this (if possible) would just be adding "xfree" to the fonts herd alias. But some sort of coverage of media-fonts is very necessary, I was noticing the lack of metadata.xml there in the past couple of days.
Created attachment 23490 [details] simple font.eclass I talked with foser about creating simple font.eclass a while ago (the one attached here is too complicated and uses chkfontpath, and he doesn't want to support it) so I wrote a new font.eclass based on another font.eclass he sent to me. It doesn't do much but will provide basic functions to install fonts under /usr/share/fonts/${PN} per fonts. (I hadn't known that every font must be installed under /usr/share/fonts/${PN}, regardless of its format)
@ eclass. There are a few things that i would change here. Actually i would basicly go back to my initial eclass, with the split up of individual font configuration steps as you've done here for clarity sake. Besides that i don't see much merit in your additions (yeah i'm not easy ;)) : 1. the var declarations. The whole if-then stuff i consider unneeded cruft, i really don't see what it adds. Just declare FONT_SUFFIXES with a little comment, it should always be reset by the ebuild. 2. Adding the FONTPATH. We don't need to set the fontpath. The very idea is that the installation path is uniform and directly related to the ebuild name (/usr/share/fonts/${PN}). I see no reason to override it and so no need to give the option. If for some reasons somehow someone needs it to be different they can override functions. 3. postinst & postrm , these are the things we are trying to avoid really. We do the initial steps for this process granted, but it sounds here like this is a mandatory step for a useful fonts setup, it just isn't for most people (but i'll get to that later). The place for this would be a font install document in my opinion. 4. what is the shopt blah for ? I had never heard of that function and don't really see what it adds here ? 5. Again an if-then of dubious necessity Most of these points come down to cleanliness. I like my eclasses to be as clean as possible, clarity & simplicity makes it easier to understand and work with it. @ font.eclass in general : in #10 puts in short my opinion on the initial eclass in this bug. I don't like chkfontpath for different reasons, but most of all i just don't see the necessity of using it anymore. A general user system consists mainly of applications using xft2/fontconfig2 by now, i don't think it should be the font.eclass priority to support every legacy font system out there. I think we should support current progress in the fonts area, not trying to solve problems that got solved for us. Legacy system support should go as far as a reasonable default xfree setup (which it is atm) and documentation on how to add fonts to legacy systems like xfont/xft1/xfs. Note that my eclass predates any eclass in this bug and was created quite a while ago shortly after the move to xft2. It was sort of put on hold because i wanted to wait for the xfree font split-up that was in progress then (i'm not sure on the status of that?) and this would be part of the whole 'redesign'. Most of my views on this got formed then by discussion and looking into this, but i still consider them valid points and i think they make sense to follow (eg. the consistent installation path).
Thanks for the comment. In short, do as you please, foser. First of all, as you pointed out, all the if-then stuff is unnecessary. I added that in case font.eclass overrides ebuild preset variables, but that's not what is likely to happen (we usually inherit eclass at the top of ebuilds). Second, about FONTPATH. I put that there because some fonts might need different font localtion. For example, if we want to install some third party fonts we would install them to /opt or whatever. (It is not unusual to buy commercial fonts and use it under X in Japan) matsuu and I committed media-fonts/acroread-asianfonts, which is installed into /opt/Acrobat5/Resource/Font and I think it is the write place to install it. Third, I added postinst and postrm because there still are some important apps that don't support xft. Kterm and rxvt are the most famous terminal emulators which can work well with Japanese besides gnome-terminal and konsole, but they both don't look at fontconfig. I added them just to be on the safe side but it would be enough to add font install documentation for those apps. Fourth, shopt sets nullglob, which will suppress errors in "for suffix in ${FONT_SUFFIXES}" loop when `echo *.$suffix` doesn't match any. I added it because I set the default value for ${FONT_SUFFIXES} to "pcf.gz ttf" (the majority of font ebuilds in Portage don't have both pcf and ttf fonts). If we don't set the default value and let ${FONT_SUFFIXES} MUST variable if you use font.eclass, we could write something like font_einstall() { insinto ${FONTPATH} einfo "Installing $suffix fonts..." doins *.$suffix } or just revert back your original eclass (no font_einstall). Finally, I'm not strongly insisting on any versions of eclasses I posted here. What I'm really willing to have is an open discussion & documentation about the policy of fonts handling in Gentoo Linux. I'm sorry I committed quite a number of Japanese font ebuilds without knowing the policy and I didn't ask xfree people about that (I just wrote the ebuilds looking at other ebuilds in Portage tree for exemplars). My apologies, I should have asked some of you. Now I feel I understand more about it than before.
We're hoping to at least split out the fonts from the core for xfree-4.3.0-r4. Once that's accomplished, it shouldn't be much work to split the fonts build into its constituents.
*** Bug 44855 has been marked as a duplicate of this bug. ***
foser, when do we put fonts.eclass into portage?
have the fonts been splitted from xfree? what about xorg-x11?
Not necessarily a top priority at this point, I'm waiting to hear what xorg upstream will do regarding a modular build.
Finally added this to the tree. Check it out, it's pretty basic. Since font packs differ so much I think a lot of ebuilds still need to do things by themselves (in the compile/unpack) phase. I suggest we first fix current font ebuilds in the tree to work with the eclass, to see what needs to be improved in the eclass. I've started with artwiz (moved to artwiz-aleczapaka-en in the process), ttf-bitstream-vera & lfpfonts-var . I made fontconfig a must have dep for this eclass. This may in rare cases not be needed, but I don't think it's worth the effort since after all the eclass is primarily aimed at xft2/fontconfig. Plus that it is needed that all fonts eclasses always do their own fc-cache magic for proper portage support, this is the only way to ensure that. Other packages calling fc-cache should not call it with the '-f' option anymore, that will cause all caches to be updated and portage won't uninstall font packs using the eclass neatly after that.
fontconfig itself got fixed not to use '-f' anymore in the ebuild
*** Bug 65634 has been marked as a duplicate of this bug. ***
About the install location. I see that font_src_install() (at least the one in the portage tree) assumes "/usr/share/fonts/${PN}". Is that such a good idea? After all font.eclass doesn't take care of font configurations for me, does it? 1. It doesn't fix my xorg.conf, and that is where my font paths are set up (and I would rather it doesn't touch it). 2. It doesn't know how to fix the ghostscript font configuration 3. There are also the java packages. sun-jdk has its own configuration. 4. There are probably others I cannot think of (someone mentioned jfbterm, etc?). Adding paths to the X configuration in the eclass is not the proper solution. Better put all fonts in one location and run mkfontdir in postinst, rather than putting every font in its own directory. My grudge is mostly against the current location of kochi-substitute, which is vital in my setup. I have to fix the setup of sun-jdk and ghostscript installations every time I upgrade the packages. And ghostscript needs to know font locations at compile time, if it is to use them when printing (bug#56998).
1. see comment #11 2. not in this bug, but our latest ghostscript uses a fontconfig patch & installs the gs fonts in the correct prefix afaik. So if kochi-substitute is in the default location at least recent ghostscript should pick it up just fine. 3+4 needs to be fixed if it is really an issue At this point this bug is still open for a reason, this move is not finished yet, but we're making our way to the set goal of a uniform way of handling fonts in Gentoo.
Perhaps about time to close this?
Closing, irrelevant bug.
