NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/text/tex/14791

Internet Message Format | 1993-01-09 | 1.7 KB

Path: sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!gt
Newsgroups: comp.text.tex
Subject: DPL - humanly readable DVI format.
Message-ID: <[e-mail]>
From: [e-mail] (Geoff Tobin)
Date: Sat, 9 Jan 1993 09:45:23 GMT
Sender: [e-mail] (USENET News System)
Organization: Department of Electronic Engineering, La Trobe University
Lines: 30

From a programmer's point of view, I've been dissatisfied with
"dvitype".  So I read TUG's "The DVI Driver Standard, Level 0"
document, available from ftp.uni-stuttgart.de, to quickly learn how
a binary DVI file is structured.

I decided to use the notation used in the Driver Standard as 99.7% of
a humanly readable DVI-equivalent language, which I call "DPL" (for
"DVI Property List", or "DVI Page Language", if you like).

Then I wrote two C programs, "dv2dp" and "dp2dv", to convert DVI files
to and from DPL format.  To my relief, "the loop has closed" on DVI
files so far.

dv2dp is quite fast, but dp2dv runs much slower, presumably due to
such things as a slow, naive, pattern matching algorithm.

DPL files are much larger than DVI files, but I think of them as a
learning tool.  It's interesting to see what TeX produces.  Maybe DPL
can help with debugging in a less verbose way than dvitype's output?

Is anyone interested in dv2dp.c and dp2dv.c ?

PS:  Perhaps a slightly higher level representation than DPL would be
feasible.  If the pointers were replaced by a more robust construct -
using labels, for example - then it might be feasible to sensibly edit
a DVI file.  I'm not asserting that that would be useful.

Geoffrey Tobin
[e-mail]
[e-mail]