Hi, On Mon, Mar 10, 2003 at 02:53:17AM -0500, Colin Walters wrote: > So, up till now fonts in Debian were supposed to be installed via > Defoma. Defoma has worked fairly well, but it's Debian-specific, and > very complex. > > Now however we have fontconfig, which is a more generic way for > applications to find and use fonts. Besides core components like GNOME, > KDE, and Mozilla, other applications like magicpoint are now using it as > well. I think we should encourage this. > > Defoma is not really supported by its maintainer anymore (see #180188), > and I think that we should be moving away from using Defoma, and > encouraging upstreams to support fontconfig. They are not entirely > duplicates really; Defoma as I understand it is just kind of a trigger > mechanism, and can help non-fontconfig applications to support a variety > of fonts. > > Now, to the issue at hand: after installing a font package, fc-cache > must be rerun. Now, we could continue to use Defoma, and I could have > fontconfig install some sort of Defoma trigger to make Defoma rerun > fc-cache. > But given the above, I would prefer for font packages to just invoke > fc-cache directly in their postinst, and also for them to Depend on > fontconfig. May I object? Fontconfig is a large, non-language neutral programmatic interface that would have to be universally adopted for this solution to work. The basic idea with font management is that you want either a push mechanism to notify "subscribed applications" of changes in your font list, or a universal pull mechanism that can be called by applications. Properties of push mechanism (Defoma) + notifications can be application specific, so support can be implemented for anything - potentially complex; font manager is hard to maintain because it must support each application's own way of dealing with font metadata. Properties of a pull mechanism (Fontconfig) + may be simple and straightforward if it has a good protocol/API - support must be implemented in each application instead of just the manager. Looking at these lists, I agree with you that it would be preferrable to encourage applications to use a universal pull mechanism, but a big API such as offered by Fontconfig is not the best candidate for such standardization, IMHO, as it will not improve the likelyness of universal adoption. I think a two-way approach would be best: 1. design a common information base containing everything you'd ever want an application to know about the list of available fonts on a system; 2. retain a push-mechanism so that old applications can be notified of changes in relevant parts of this font information base; 3. encourage new applications to use this information base directly, possibly through a simple library, but ideally it should be simple enough for non-expert programmers to access directly. Of course, this could all be done with fontconfig as the common part, but I'd be /much/ happier with a simple directory tree that provides a few indexes through symlinks. If you go from a concept that circles around font files that may reside in random places, where each font file may be of a particular type (eg. TrueType, Type 1, or PCF - known from its extension), and each font file may contain multiple faces, but also requiring that each font family may have its faces (bold/italic) in different files, you could create a simple information base like this: fontinfo/byfamily/<family>/<face>/<size> -> </path/to/fontfile.ext> fontinfo/bypsname/<psname>/<size> -> </path/to/fontfile.ext> So, you'd have byfamily/Times New Roman/Bold/0 -> /usr/share/fonts/truetype/timesb.ttf byfamily/Times New Roman/Italic/0 -> /usr/share/fonts/TrueType/timesi.ttf byfamily/LucidaTypeWriter/Bold/12 -> .../X11/fonts/75dpi/lutBS12.pcf.gz byfamily/LucidaTypeWriter/Bold/14 -> .../X11/fonts/75dpi/lutBS14.pcf.gz bypsname/Helvetica -> someotherfile Of course, applications are free to walk this once and cache a subset of their own, as long as they pay attention to eg. the mtime of the fontinfo directory and regenerate their local cache when necessary. Substitution is easy with such a scheme as well. Parts of defoma could be kept to notify old applications of changes and convert the tree into whatever application-specific format, and new ones can use the trees directly. Ghostscript could get a patch so it could use the 'bypsname' directory in addition to its Fontmap files. I'm not claiming this as an do-all, end-all solution; I haven't even fully thought this out, and there may be much better schemes than byfamily and bypsname, but I hope you'll consider something /simple/ and language-neutral like this before you require each application to adopt fontconfig in order to become aware of fonts installed by dpkg. Cheers, Emile. -- E-Advies / Emile van Bergen | emile@e-advies.nl tel. +31 (0)70 3906153 | http://www.e-advies.nl
Attachment:
pgp5avKfz7wlb.pgp
Description: PGP signature