On 12/5/2015 5:41 PM, Karl Berry wrote:
So, it appears a bad DVI file is being created by dviluatex. That should never happen and thus is something we should report to them. However, we have to be able to provide input that they can run directly with the engine binary, not using make4ht. Copying the dvilualatex command from the make4ht output and running it by hand results in a perfectly fine .dvi file.
Aha! But it does not on my end? Why? I deleted the .dvi file. Run the dvilualatex command. I see no error message on screen, but when I did dvitype, I still get the same error! Please see: -----------------------------------
rm KERNEL.dvi
rm: remove regular file ‘KERNEL.dvi’? y
dvilualatex -jobname=KERNEL '\makeatletter\def\HCod......(long command!
[1] (./KERNEL.aux)) (see the transcript file for additional information) 265 words of node memory still in use: 2 hlist, 1 vlist, 1 rule, 2 glue, 40 glue_spec, 1 write nodes avail lists: 2:17,3:6368,4:21965,5:1441,6:13424,7:3,9:10891,10:25 Output written on KERNEL.dvi (1 page, 208428 bytes). Transcript written on KERNEL.log ------------------------------------ Ok, no error, but the DVI file is bad: ---------------------------------------
dvitype KERNEL.dvi
This is DVItype, Version 3.6 (TeX Live 2015) Options selected: Starting page = * Maximum number of pages = 1000000 Output level = 4 (the works) Resolution = 300.00000000 pixels per inch numerator/denominator=25400000/473628672 magnification=1000; 0.00006334 pixels per DVI unit ' LuaTeX output 2015.12.05:1815' Bad DVI file: byte 208301 is not post! --------------------------------------- So does this mean dvilualatex is generating bad dvi?
So something more is happening in between runs, probably generation of intermediate files, but I don't see any obvious way to determine what's needed to reproduce. Also, it could be helpful for make4ht to run dvitype on any .dvi file right after it is created, so that the error can be caught as soon as possible in the process. Also, I think it would be helpful to add a -recorder option to make4ht, since what we really want to do is bundle up all the input files to give to the luatex developers, along with the command line to reproduce that problem. And the recorder file is what would tell us for sure what input files are needed. I suppose it could all be figured out from strace output, but it would be much simpler to get it from make4ht. So, Michal ... wdyt? Can you add stuff to help debug this to make4ht? (BTW, it would also be conventional to actually recognize --help and --version, and send their output to stdout instead of stderr, and exit successfully. Anyway ...) Thanks, Karl
thanks, --Nasser
