Bugzilla Bug 13808

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 an attachment (id=7236) [edit]
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 an attachment (id=12570) [edit]
font.eclass

fixed.

Created an attachment (id=16858) [edit]
font.eclass

Created an attachment (id=16859) [edit]
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 an attachment (id=20837) [edit]
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 an attachment (id=23490) [edit]
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.