[tlbuild] dvi test?

[Paul Vojta]

Regarding fseek, etc., and the dvi file, could someone send me the output
of "xdvi -debug 34 -noghostscript t2a.dvi" (in a situation where the bug
occurs)?

Here 34=2+32, where 2 asks for debugging the bytes read from the dvi file,
and 32 asks for debugging the ps calls.  The latter is just to be sure that
the -noghostscript option isn't somehow being ignored.

By the way, I asked about -debug 256 only to make sure that the font setup
on your machines wasn't any different from mine.  In particular I wanted to
be sure that there weren't any virtual fonts involved (there weren't).
That question has now been answered, so -debug 256 is no longer useful.

Paul


On Sat, Jan 29, 2022 at 03:56:00PM -0700, Karl Berry wrote:
> 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.