Re: [Gnome-print] gnome-font-install and packaging

[Lauris Kaplinski <lauris ximian com>]

Hello Owen!

Yes, this program is ugly little thing, that gnome-print inherited
from ancient times (well there was fontmap instead of fontmap2
then...), and which original idea was to locate during tarball
installation time well-known type1 fonts from system.
The future is brighter, as I think XST font tool will be used
to manage gnome-print fonts, but until then...

On 20 Jul 2001 19:53:17 -0400, Owen Taylor wrote:
> 
> I'm working now to fix up our gnome-print package to be somewhat more
> robust and sensical. In particular, I've run into some issues with
> how gnome-font-install is supposed to work.
> 
> * I don't believe the location of the fontmap2 file
>   in ${prefix}/share/fonts is correct. I'm not sure whether to categorize
>   this file as a configuration file, or a cache file, but in either
>   case, it doesn't belong in /usr: it's contents are dynamic, and it
>   might include files that are in directories outside the user hierarchy
>   such as /opt.
> 
>   (We at Red Hat have an informal policy that every file in /usr must be
>   come from some package... dynamically generated files can't be in /usr)

Agree. It probably should go to /etc/fonts or /etc/gnome/fonts

> * I don't really understand the intended mode of operation of 
>   gnome-font-install. Currently all packages I know of gnome-print
>   (Ximian, Red Hat, Plain GNOME), install run-gnome-font-install somewhere,
>   run it when installing gnome-print. 
> 
>   This picks up at least some of the fonts that are be on the system 
>   when gnome-print is installed, but unless the gnome-print package
>   explicitely as a PreReq on a font package, the font package might
>   well be installed _after_ gnome-print. (The Red Hat packages PreReq
>   the urw-fonts, so at least those get found.)
> 
>   I get the idea that the envisioned usage is a little different -- 
>   perhaps each font package is supposed to drop a .font file for
>   itself into a standard location, then, if gnome-print is installed,
>   run:
>          gnome-font-install -f /standard/directory

AFAIK (I cannot tell about Raph original intentions)
run-gnome-font-install.pl
should not be used by packaged product. Its only function is to locate
ghostscript include paths, and feed these to gnome-font-install as
assignments. This has meaning only if compiling from tarball - packages
(including src ones) are supposed to know, where gs fonts are installed
on target system.
Each font package including .font file is good idea IMHO. It should be
tailored to target system, i.e. include absolute paths, so there is
no need for assignments etc.

> * It's impossible (as far as I can tell), to remove fonts from the 
>   knowledge of gnome-print without actually removing them from 
>   the system. (Or blowing away your fontmap2 and starting over.)

You are right.
It is not real font solution for users - the latter should have GUI
and manage mapping X/gnome-print fonts together.

> * I think it's probably wrong that gnome-font-install when run with 
>   --target= reads in the current contents of ${prefix}/share/fonts/fontmap2 
>   instead of the new target file. As far as I can tell, if I was using
>   gnome-font-install to maintain ~/.gnome/fontmap, then I'd have to
>   include all my personal directories every time.

It reads both ${prefix}/share/fontmap2 and ~/.gnome/fonts/fontmap. I
think
it would make sense to add a way to read arbitrary fontmap file - but
reading
only --target is not good idea IMHO - in case you want to generate some 
tempfile or something...

> I don't have a lot of recommendations of how things should work at the
> moment ... still thinking about that. But it seems somehow that there
> should be a better separation between:
> 
>  * Configuration - what font directories and/or fonts do I have
>    installed on my system.
> 
>  * Cached state about what is known about the system state.
> 
> Reactions?

I agree 99% with you.
I have following vision:
Somewhere (in etc/fonts?) lie some standard font db files, that are
installed by packages, giving:
- Face description properties (family, style...)
- Physical file location
- File format
- Coverage? (this is probably tricky)
- Aliasing (we know, that URW-something is the same as Helvetica)
Each subsytem could now have simple (set of) script(s), that parse
standard db files, and maintain per-subsystem database.
This would make things like matching X and gnome-print fonts much
easier, as users/admins could add customized rules etc.

PS. I got 3 good ideas from you:
1. fontmap location should be specifiable compile time
2. There should be way to remove fonts from db
3. Instead of monolithic fontmap file, gnome-print should parse
   directory of *.fontmap files, so packages could just drop
   files in, and users can make single-font .fontmap files easily
These are for HEAD/2.0 unless XST takes the burden.

Btw. How do you plan to manage PangoFT2 fonts?
I have to do PangoFont -> GnomeFont bridging for libgnomeprint-2. It
would be relatively easy to do for FT2 fonts, as new gnomefonts are
wrappers around FT_Face, but:
- For quite a time in future, people are interested in mapping
  from PangoXFonts <-> GnomeFonts, so if they have rich PangoX
  font population and nonexistent PangoFT2 one, things are bad
- I need physical files for embedding, and PangoFontFT2 gives me
  only FT_Face.
The alternative would be to turn things around, and create
GnomeFont -> PangoFont bridge. It would make sense for strictly
WYSIWYG applications, as these are only interested in printable
fonts anyways, but I imagine apps that have switchable Gdk/aa
canvas modes would not like such restriction.
Another alternative would be to drop GnomeFonts/Faces completely
- but I want some higher-level FT wrapping to be present, and
I do not think Pango wants such bloat.
Any suggestions?

Best wishes,
Lauris Kaplinski

> [ 
>   Font cataloging is, of course, a much more general problem - systems
>   using Type1 and TrueType fonts shipped with Red Hat include at least:
> 
>     xfs, libXft, VFlib, a2ps, gnome-print, ghostscript, groff, Tex
> 
>   Each of of these has a separate method of locating fonts and
>   information about fonts... :-(  Programs/systems for updating
>   font catalogs include:
> 
>    ttfm, ttmkfdir, chkfontpath, gnome-font-install, mkfontdir
> 
>  Some postulates about how font installation should work:
>  
>  * Packages of fonts when installed or removed should update cause
>    all relevant font catalogs to be updated. This should be 
>    robust against the order installation of the font packages
>    and the systems using various catalogs.
> 
>  * System adminstrators should be able to add and remove fonts
>    from all relevant catalogs with one centralized tools without
>    going through the packaging systems.
> 
>  * Users should, to the extent that the relevant systems allow it,
>    be able to augment their fonts with personal fonts not in 
>    their home directories.
> 
> ]
> 
> 
> _______________________________________________
> Gnome-print maillist  -  Gnome-print@ximian.com
> http://lists.ximian.com/mailman/listinfo/gnome-print