> I think it's likely, if the program scanned ahead in its input--or > equivalently, kept a memory of trout commands already seen--to detect > line breaks advertised by the `n` command. > > groff_out(5): > n b a Indicate a break. No action is performed; the command is > present to make the output more easily parsed. The integers > b and a describe the vertical space amounts before and after > the break, respectively. GNU troff issues this command but > groff’s output driver library ignores it. See v and V.
Right. I did consider this precisely _after_ I hit `send' on my previous reply, and then consulted groff_out(5) to verify... (I ought to think before I speak--er, write) I am not expert on microtypography, so I could totally be in the wrong here, but this approach (adjusting punctuation before all line breaks) seems maybe a bit naïve? It would also adjust punctuation at the ends of lines when left justified or centered. Perhaps because the adjustment is so small (_micro_typography) this isn't significant. With this in mind, though, I believe the hangpunc program could possibly be written in ~5 lines of sed(1), ~2 lines of awk(1) or 1 line of perl* :p --- * - of course, anything can fit on 1 line so long as you don't need it to fit in 80 columns, but I mean here that perl's regex's are powerful enough to identify punctuation preceding an n command and insert adjustment accordingly. -- S.
