roy@phri.UUCP (01/30/87)
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).
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.
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?
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
"you can't spell deoxyribonucleic without unix!"henry@utzoo.UUCP (Henry Spencer) (02/01/87)
> 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
steve@latcs1.oz (Steve Bodnar) (02/04/87)
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
berger@datacube.UUCP (02/10/87)
Speaking of vfonts..
are they public domain? Can I give them away or are they tied to berkely
and thus att licenses?
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: ihnp4!datacube!berger
{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!bergercuccia@ucbarpa.Berkeley.EDU.UUCP (02/11/87)
In article <106400002@datacube> berger@datacube.UUCP writes: > >Speaking of vfonts.. >are they public domain? Can I give them away or are they tied to berkely >and thus att licenses? > > Bob Berger > >Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960 >VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125 >UUCP: ihnp4!datacube!berger > {seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!berger The vfont fonts (well, most of them, at least) that are included with 4.[23]BSD originated at the University of Toronto, if I recall correctly. I don't know where at UT they came from, though. --Nick
henry@utzoo.UUCP (Henry Spencer) (02/24/87)
> The vfont fonts (well, most of them, at least) that are included with > 4.[23]BSD originated at the University of Toronto, if I recall > correctly. I don't know where at UT they came from, though. The ones from U of T (beware: I can offer no easy rule of thumb for deciding which ones those are!) are mostly distant derivatives of the Hershey fonts, as I recall. Some of them had quite a lot of bit-tuning done on them, mind you, and there are probably odds and ends from all manner of sources in there. This process of tuning, mutation, and cross-breeding has probably progressed further since the fonts left here. -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry