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: [email protected]
https://www.facebook.com/william.f.hammond
http://www.albany.edu/~hammond/
𝑻𝒉𝒆 𝒕𝒊𝒎𝒆 𝒕𝒐 𝒔𝒂𝒗𝒆 𝒂 𝒅𝒆𝒎𝒐𝒄𝒓𝒂𝒄𝒚 𝒊𝒔 𝒃𝒆𝒇𝒐𝒓𝒆 𝒊𝒕
𝒊𝒔 𝒍𝒐𝒔𝒕. -- 𝐊𝐞𝐧 𝐁𝐮𝐫𝐧𝐬
