You are not logged in.
This is a popular package on Linux and FreeBSD, so I thought some Arch users might want to try these fonts out too, or might remember them from their former distribution and look for a package. The "screen" fonts are exceptionally good, if you prefer a non-anti-aliased desktop. The others just come along for the ride. There is one font called "space" made up of all blanks, and I can't imagine why. Perhaps someone will know and can clue me in.
# Contributor: David Scholl <djscholl>
pkgname=sgi-fonts
pkgver=1.0.1
pkgrel=1
pkgdesc="Bitmapped X11 screen fonts from Silicon Graphics, Inc."
url="http://oss.sgi.com/projects/sgi_propack/"
license="MIT"
depends=('fontconfig' 'xorg-font-utils' 'xorg-fonts-encodings')
makedepends=('rpmextract' 'imake')
install=sgi-fonts.install
source=("ftp://patches-europe.sgi.com/pub/linux/ProPack1.4/SRPMS/$pkgname-${pkgver/%.1/-1}.src.rpm")
md5sums=('a98655922ee624a7aa8fdae161afdfa9')
build() {
cd $startdir/src
rpmextract.sh $pkgname-${pkgver/%.1/-1}.src.rpm
tar xf sgi-fonts.tar.gz
patch -p0 < ../sgi-fonts.patch
cd $pkgname
xmkmf || return 1
sed -i '/^ FONTDIR/s/$(LIBDIR)//usr/share/' Makefile
make || return 1
make DESTDIR=$startdir/pkg install
cd $startdir/pkg/usr/share/fonts/misc
mv sgi/*.pcf.gz ./
rm -Rf sgi
}
I would like to highlight the following issues.
The original distribution from SGI is in src.rpm format. I use the rpmextract package to extract the rpm contents.
The original distribution file has a hyphen in the file version, which I work around with a bash expansion.
License file
The fonts are distributed by SGI as a source rpm. In the rpm spec file, the copyright is described as "X/MIT". The bdf-format font files contain copyright statements giving the copyright date and listing the copyright holder as Silicon Graphics, Inc. However, no explicit license file is distributed with the fonts by SGI. The Arch Packaging Standards call for an explicit license file to be installed in /usr/share/licenses/$pkgname for packages under the MIT license. I have decided to specify license="MIT" but provide no license file. I think it might be OK for me to generate a license file, since the distribution states the license type, copyright holder, and copyright date. However, I am not a lawyer, so I'm not sure. I thought I should at least list the license type, since it can only be found by poking around in the rpm spec file. FWIW, the comparable font PKGBUILDS in the ABS provide no license information.
sgi-fonts.patch
The patch fixes code related to IRIX default desktop fonts remaining uncompressed, removes references to fonts not in the package, and fills in "SGI" on the six fonts with blank foundry ID's.
Imake
The sgi-fonts distribution comes with an Imakefile. The Makefile created by xmkmf installs the fonts in /usr/lib/X11/fonts, which is the location specified in /usr/lib/X11/config/X11.tmpl:
#define FontDir $(LIBDIR)/fonts
. Shouldn't there be a .def or .cf file in that directory to override FontDir to be /usr/share/fonts? Is this a bug in the imake package? For now, I have a sed command in the build script to hack the fontpath in the Makefile to /usr/share/fonts, but this seems like a kludge. The PKGBUILDS for the other bitmapped fonts in the ABS don't use imake. I thought I would submit this package to the AUR, and then file a bug report on imake. Other than this package, I don't know a simple way for the developers to confirm the bug.
Installation in sgi subdirectory
The Imakefile installs the fonts in fonts/misc/sgi, with their own fonts.dir, fonts.scale, and fonts.alias. This makes for convenient removal, but requires that the user's font paths be changed, which seems contrary to the Arch way. I have the build script move the fonts to fonts/misc, delete the fonts/misc/sgi directory, and use a conventional font install script to rebuild the fonts.scale and fonts.dir in the fonts/misc directory. This means that the distributed fonts.alias is lost, but font aliases are problematic for package removal. Perhaps this is why the mkfontdir man page says that fonts.alias files are to be edited by hand. A font alias can be anywhere in the font path and point to anywhere in the font path, so a clean automatic removal script would have to walk the tree, looking for and removing aliases to uninstalled fonts. A compromise could be to save the sgi-supplied fonts.alias and concatenate it to fonts/misc/fonts.alias, where it could be used, but to remove even the sgi section of fonts/misc/fonts.alias would require a greatly complicated install script. Does anyone find the convenience of the aliases to be worth complicating the uninstall to this degree?
Feedback, suggestions, corrections on these or any other points are welcome.
Offline
This is a popular package on Linux and FreeBSD, so I thought some Arch users might want to try these fonts out too, or might remember them from their former distribution and look for a package.
Very thorough - nice work.
There is one font called "space" made up of all blanks, and I can't imagine why. Perhaps someone will know and can clue me in.
Let's see - it would be perfect for reviewing a performance of 4' 33", or for users of the Whitespace language.
Seriously, though:
The original distribution from SGI is in src.rpm format. I use the rpmextract package to extract the rpm contents.
No problem there.
The original distribution file has a hyphen in the file version, which I work around with a bash expansion.
Probably the best solution for your own use, but it won't work in the AUR. You need to hardcode some or all of it.
License
<snip>I have decided to specify license="MIT" but provide no license file.
Works for me - you are simply reflecting what has been provided.
sgi-fonts.patch
The patch fixes code related to IRIX default desktop fonts remaining uncompressed, removes references to fonts not in the package, and fills in "SGI" on the six fonts with blank foundry ID's.
Cool.
Imake
<snip>Shouldn't there be a .def or .cf file in that directory to override FontDir to be /usr/share/fonts? Is this a bug in the imake package? For now, I have a sed command in the build script to hack the fontpath in the Makefile to /usr/share/fonts, but this seems like a kludge. The PKGBUILDS for the other bitmapped fonts in the ABS don't use imake. I thought I would submit this package to the AUR, and then file a bug report on imake.
I don't know enough about imake to say what should or shouldn't be there, but I've done my fair share of kludgey sed fixes - sometimes there's no choice, if you want a working PKGBUILD. Post the bug, and see what happens.
Installation in sgi subdirectory
The Imakefile installs the fonts in fonts/misc/sgi, with their own fonts.dir, fonts.scale, and fonts.alias. This makes for convenient removal, but requires that the user's font paths be changed, which seems contrary to the Arch way. I have the build script move the fonts to fonts/misc, delete the fonts/misc/sgi directory, and use a conventional font install script to rebuild the fonts.scale and fonts.dir in the fonts/misc directory. This means that the distributed fonts.alias is lost, but font aliases are problematic for package removal. Perhaps this is why the mkfontdir man page says that fonts.alias files are to be edited by hand. A font alias can be anywhere in the font path and point to anywhere in the font path, so a clean automatic removal script would have to walk the tree, looking for and removing aliases to uninstalled fonts. A compromise could be to save the sgi-supplied fonts.alias and concatenate it to fonts/misc/fonts.alias, where it could be used, but to remove even the sgi section of fonts/misc/fonts.alias would require a greatly complicated install script. Does anyone find the convenience of the aliases to be worth complicating the uninstall to this degree?
I'l happily admit that I don't know what fonts.alias is for, but if it's not essential, and if it increases complexity, leave it out.
Offline
Thanks for the feedback. I have hardcoded the version numbers in the tarball filenames in the PKGBUILD and submitted the package to the AUR.
Offline
Bug FS#5027 (imake package sets incorrect fontdir) has been fixed in the the new imake 1.0.2-1. Accordingly, I removed the workaround sed hack from the PKGBUILD and uploaded sgi-fonts 1.0.1-2 to the AUR. The bug only affected the makepkg step, so only users running makepkg with the new imake need the new release.
Offline