[tlbuild] dvi test?

[Karl Berry]

Thanks Bruno.

    xdvi-xaw: set_no_char: attempt to set character of unknown font, offset 42

My wild speculation is that something goes wrong with the reload --
maybe some permission problem related to the ever-worsening "security"
in the latest mac versions.

Then, the reloaded file doesn't get read, and thus the fonts can't be
defined, thus the error.  The first DVI page starts at byte offset
42. In the other words, maybe the error is just the first thing that
xdvi happens to notice, not that fonts that are the source of the
problem (indeed, I can't see how they could be).

However, normally xdvi would notice any failure in re-opening the file.
There are too many branches in the load_dvi_file routine (in
dvi-init.c), which I believe is what gets called by 'R', for me to be
able to guess at what is happening. Running under a debugger/print
statements is needed.

One minor thing that I see is that the return value from fseek is not
being checked here (line 1821):
	fseek(m_dvi_fp, 0L, SEEK_SET);
although I don't know if that's even being called.

Regarding the need for draftcopy, I believe its only result in the dvi
file is a longish (~640 bytes) xxx special at byte offset 143:
143: xxx '! userdict...
Running with -noghostscript, it's hard to see how that makes any 
difference beyond increasing the size of the dvi file.

DVI file format is 100% independent of anything about the system
architecture.

I am doubtful that there is any generic bug/system dependency in the
fundamental dvi parsing. xdvi has been around 30+ years, used on every
conceivable X-supporting system. Something in the latest Apple OS's
breaking some long-held assumption about file access seems more likely
to me. --best, karl.