Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Font Question
Message-ID: <9011101714.AA07255@expire.lcs.mit.edu>
Date: 10 Nov 90 17:14:33 GMT
References: <HARKCOM.90Nov10120201@potato.pa.Yokogawa.Co.jp>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 19


     Are all of the undefined characters between 00000000 nnnnnnnn and
     1nnnnnnn nnnnnnnn taking up memory?

The font gets compiled with a matrix encoding (see the X protocol doc for
a description).  bdftosnf computes the "minimum" bounding matrix encoding.
The font file contains (all-zero) metric information for each valid column
in each valid row between the first and the last rows.  There are 16 bytes
of metric information for every such glyph.  If the font gets compiled with
ink metrics in addition to bitmap metrics, then there will be two sets of
metrics in the file, making it twice as large.

    But why does the server suck up more than twice the font's size to hold it
    when smaller fonts barely take up their size in memory?

Depends to some extent on how your system's memory allocator works.  But in
addition, if your client queries for the font metrics (e.g. XLoadQueryFont),
then the server will temporarily allocate a large buffer to copy metric
information into, and this buffer will be several hundred K.