[Dev-luatex] On \maxdimen in LuaTeX

Hans Hagen j.hagen at xs4all.nl
Tue Jun 11 18:22:58 CEST 2019


On 6/10/2019 1:25 PM, Sjors Gielen wrote:
> Hi all,
> 
> According to the TeX in Practice book, "the largest dimension value that 
> can be represented in a TeX program is 16383.99999pt. This value is 
> assigned to a dimension register \maxdimen [...]." This is a tiny bit 
> smaller than 2^14 pt. As a layman TeX user, my naive guess is that in 
> the compiler, floating point dimension registers probably use int32_t or 
> some other fixed-length type, and the compiler implements its own 
> floating point arithmetics. Either way, whenever an overflow is going to 
> happen, the compiler prints a "! Dimension too large" error.
> 
> This error also occurs when using LuaTeX. My gut feeling is that the 
> current limit of (almost) 16384 pt is perhaps mostly historic; could it 
> nowadays be loosened somehow? Perhaps the dimension calculations are 
> already in Lua and the error is there for legacy reasons, or perhaps the 
> calculations are still in C and if int32_t is indeed used, int64_t could 
> conceivably raise the max dimensions to hundreds of kilometers, more 
> than anyone would accidentally reach.
> 
> Looking forward to hearing your thoughts.

changing a 'scaled' to 64 bit has lots of implications like changing the 
node memory properties (multiplying mem), all kind now int's becoming 
longs and therefore also quite some instability for a while

when you use \dimexpr valuesx can be larger till the result is known

actually you can create a box larger than maxdimen and split off bits 
because tex doesn't always check

so: very unlikely to change

> Best,
> Sjors Gielen
> 
> P.S.: The discussion I am hoping to invoke is theoretical, but for 
> background, my motivation comes from the use of the 'mdframed' package 
> to split a large frame over many pages. Our automated testing system 
> creates mdframed environments containing test steps and their outcomes; 
> we have apparently crossed some new amount of steps where the virtual 
> vbox size goes over \maxdimen before the vbox is split over multiple 
> pages. If the error is ignored, the generated PDF looks fine. We can 
> also end the mdframed environment every N steps and immediately start a 
> new one, which is an acceptable workaround but I'm a bit unsatisfied 
> that it's necessary. Perhaps this is better considered a bug in mdframed 
> than in the typesetting engine, but I still find the theoretical 
> question behind \maxdimen interesting, hence this e-mail.
> 
> _______________________________________________
> dev-luatex mailing list
> dev-luatex at ntg.nl
> https://mailman.ntg.nl/mailman/listinfo/dev-luatex
> 


-- 

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------


More information about the dev-luatex mailing list