At 2024-11-08T17:20:05+0100, Oliver Corff wrote: > Again the problem of search terms... OF COURSE line length -> LL is > what I searched for, alas! I thought in terms of TeX terminology: > \textwidth which would lead nowhere.
It's not exactly wonderful that the most likely mnemonic for the `\w` escape sequence is "width", which measures a horizontal distance just like `\l` and `\n[.l]` do. This is another regrettable consequence of too swift an acquiescence to the Ken Thompson minimal hash function principle. Or of not having enough memory in one's PDP-11/20. There's probably enough blame to go around. > \n[LL] produces 468000. I tried \l'\n[LL]/10000' but get an "error: > numeric overflow" message. > > Taking advantage that a register ll is undefined in ms I tried then: > > .nr ll \n[LL]/10000 > \l'\n[ll]' > > That basically does the trick but unfortunately 468000/10000 yields > 46, not 46.8 in groff (due to groff performing truncating division as > mentioned in the documentation). > > How can I tweak the arithmetic operation to set the correct value of > 46.8? Or can I bypass the whole truncating division issue by a smart > selection of scaling units? I _might_ have some advice. But I need to know more. Why are you dividing by 10,000? What it is you're trying to achieve? I feel sure you're not actually trying to draw a rule one ten-thousandth of the line length in _any_ environment. Part of the problem might be the `\l` escape sequence trying to impose its "native" scaling unit of "m" on arguments as soon as it reads them. Observe: $ ./build/test-groff -ww -b -ms .LP Hello. .br \l'\n[LL]/10000u' troff: backtrace: file '<standard input>':4 troff:<standard input>:4: warning: integer value saturated .nr a \n[LL]/10000u .pnr a a 46 0 \l'(u;\n[LL]/10000)' No warning arises from the second use of `\l`. Here's a cleaner exhibit. $ cat EXPERIMENTS/short-hrule.ms .LP Hello. .br \l'\n[LL]/10000u' .br \l'(u;\n[LL]/10000)' Regards, Branden
signature.asc
Description: PGP signature
