🚀 go-pugleaf

In article <2583@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:

>	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'm
>working from the 4.2 man page, and trying to get this working on both Vax
>and Sun systems (yes, I know about vswap).

I have a converter that swap bytes and can handle a computer 
that has 4 byte boundaries, instead of 2 bytes. (done dynamically).

>	From looking at octal dumps, I figured out that if you take the
>dispatch.addr field and add it to sizeof(header) + 256*sizeof(dispatch) you
>get something you can hand to seek().  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.

Note: 
sizeof(header) on a vax is 10.
sizeof(header) on a pyramid is 12.
(my program fixes this)

You seek to sizeof(header) + 256*sizeof(dispatch) + dispatch.addr from
beginning of the file.
Note: sizeof(dispatch) has same problem as sizeof(header).

>	My real question is about the redundancy in the dispatch.addr and
>the dispatch.nbytes entries.  You can calculate dispatch[n].addr as SH +
>256*SD + sum from i=0 to n-1 {dispatch[i].nbytes}, where SH = sizeof
>(struct header) and SD = sizeof (struct dispatch), assuming that the
>bitmaps are in order and close packed.  Is this a valid assumption?  If I
>want to be careful that I'm not eating a random file (more careful than
>just checking the magic number), can I check that the above condition is
>true and complain about a badly formated file if it's not?

You also have some files in reverse order, so you definitly need dispatch.addr.
Note, that is on oldenglish i think.

---------------------
Steve Bodnar,			ISD:	+61 3 478-3122 ext 2393
Department of Computer Science,	STD:	(03) 478-3122 ext 2393
La Trobe University,		ACSnet:	steve@latcs1.oz
Bundoora,			CSnet:	steve@latcs1.oz
Victoria, 3083,			ARPA:	steve%latcs1.oz@seismo.arpa
Australia			UUCP:	...!seismo!munnari!latcs1.oz!steve
					    hplabs
					    mcvax
					    ukc
					    nttlab