[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fonts



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: pgpb7RAuQKNBI.pgp
Description: PGP signature


Reply to: