Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.text,comp.unix.wizards
Subject: Re: Questions about vfont file format
Message-ID: <7604@utzoo.UUCP>
Date: Sun, 1-Feb-87 02:21:55 EST
Article-I.D.: utzoo.7604
Posted: Sun Feb  1 02:21:55 1987
Date-Received: Sun, 1-Feb-87 02:21:55 EST
References: <2583@phri.UUCP>
Organization: U of Toronto Zoology
Lines: 50

> 	I'm trying to write some utilities to work with vfont files, but
> the vfont(5) man page is not entirely unambigious on a few points...

I think I can answer this one.  I've recently gotten, um, intimate with
that format, and I've been doing conversions back and forth from another
format and comparing results.  So the following is pretty sure to be right.

> ...  From the man page, it is not really
> clear if dispatch.addr is an offset from the beginning of the file (from
> the name, you would guess this is right, silly you), from the beginning of
> the bitmaps, or maybe even from the beginning (or end??) of the dispatch
> structure for that particular glyph.

From the beginning of the bitmaps.

> 	My real question is about the redundancy in the dispatch.addr and
> the dispatch.nbytes entries... assuming that the
> bitmaps are in order and close packed.  Is this a valid assumption? ...

The ones I've seen and built are always that way, probably mostly because
in practice there's no good way to operate on the format without working
on a temporary copy and then rebuilding the whole thing.  However, there
is no official guarantee of this, and I would suggest not relying on it.

> If I want to be careful that I'm not eating a random file ... can I check
> that the above condition is true and complain about a badly formated file
> if it's not?

I would be wary about this.  The farthest I would go would be to query use
of such a file, as opposed to rejecting it.  You might want to consider
more subtle redundancy checks, like verifying that height and width are
consistent with number of bytes allocated for the glyph, verifying that
the offsets point within the file, checking that the (up,down,left,right)
specs are internally consistent (i.e. rectangle of non-negative dimensions),
etc.  I would think it vanishingly unlikely that a random data file would
meet all these constraints, and these are things that *must* be true (or
at least are *much* less likely to be violated deliberately).

One thing I strongly recommend doing, regardless:  if you are willing to
reject a font file for flunking a constraint that might be legitimately
violated (like glyph ordering), for heaven's sake provide a way for your
poor suffering users to fix the offending font file!

P.S. Don't check maxx and maxy for consistency with the actual maximum
height and width of the glyphs -- for some reason, maxx and maxy are often
rather larger than they need to be.  Also, the officially-unused xtend
field often has a non-zero value in it.
-- 
Legalize			Henry Spencer @ U of Toronto Zoology
freedom!			{allegra,ihnp4,decvax,pyramid}!utzoo!henry