Thanks, Werner and Tadziu, for the prompt replies! That clears a few things up.
Yes, I had read the Measurements section of the manual, but that's part of what confused me about the .V register. Where that section said "This basic unit, represented by a 'u', is a device dependent measurement," I took that to mean that the groff basic unit corresponded to the output device's resolution, but this seems to not (always) be the case, according to Tadziu's detailed explanation. There is probably a clearer way to word all that in the manual. Anyway, it turns out to be unrelated to the issue I was trying to solve, that of page-location traps. > Reason is that traps are not recursive, IIRC: Traps are not handled > while another trap is active (this seems to be missing in the info > file). I'm not sure expected them to be, but the real problem seems to be: > In other words, while your first trap is active, it moves down > one line, which passes some traps without triggering them. That bit of information is missing from the manual as well, but more importantly, doesn't even seem like desired behavior for the traps as written. Nothing in them should cause vertical movement. (Indeed, vertical spacing in the output looks consistent whether or not a trap was executed between two lines.) > Below is an example that triggers all defined traps if called with the -Tps > device. Hmm. When I run it, it overprints some output lines atop each other, also not a desired result. (And it additionally creates an infinite loop when I change the .nop to .tm so the trap notices to go stderr rather than the ps output.)
