[tex4ht] [bug #618] Incomplete XML Document, domfilter error, truncated build on large file.

[William F Hammond]

Karl Berry wrote:
...

> \count255=0
> \loop\ifnum\count255 < 65600
>   \advance\count255 by 1
>     x\vfil\eject
> \repeat
> \end
>
...

Thanks, Karl!

I put this code in karlBerry65600pp.tex and called TeX.

Then:

dv2dt  karlBerry65600pp.dvi  >  karlBerry65600pp.dtx
grep  '^bop'  karlBerry65600pp.dtx  |  wc
    65600  787200 2337707

(And likewise for '^eop'.)

Taking a look at the DVI Standards Doc in Tugboat

https://mirror.las.iastate.edu/tex-archive/dviware/driv-standard/level-0/dvistd0.pdf
I see:

post p[4] num[4] den[4] mag[4] l[4] u[4] s[2] t[2]

The blurb says that  l and u are often ignored, so there is precedent for
ignoring some
of these fields.  Clearly, the last field  t  (number of bop commands)  is
redundant.  A modern DVI processor could pre-process a large DVI file, say
as above in the shell, to determine the page count.

Nasser said that he had no problem with the PDF.  Given that, I think that
if tex4ht is to be
maintained for the long haul, it should be possible to remove the 2^16 page
limit in tex4ht.

You mentioned that there may be other capacity limitations, say, for
example, with dvips.  But as I recall, the dvi's generated by tex4ht
sometimes are not good for dvips anyway.  The question is whether serious
capacity limitations might lurk for tex4ht.  It might be so, but I don't
see any reason to jump to that conclusion.

However, I'm fine with your conclusion regarding the document at hand.

Best,

         -- Bill

William F Hammond
Email: gellmu at gmail.com
https://www.facebook.com/william.f.hammond
http://www.albany.edu/~hammond/

𝑻𝒉𝒆 𝒕𝒊𝒎𝒆 𝒕𝒐 𝒔𝒂𝒗𝒆 𝒂 𝒅𝒆𝒎𝒐𝒄𝒓𝒂𝒄𝒚 𝒊𝒔 𝒃𝒆𝒇𝒐𝒓𝒆 𝒊𝒕
𝒊𝒔 𝒍𝒐𝒔𝒕.   -- 𝐊𝐞𝐧 𝐁𝐮𝐫𝐧𝐬
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex4ht/attachments/20231218/681ec80a/attachment.htm>