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