Time for a little thread necromancy. And a bit of 1.24.0 status. At 2023-04-25T10:05:14-0400, Douglas McIlroy wrote: > > $ ./build/test-groff -Tutf8 > .> nr a 3c > > .nr b 3cm > > .tm a=\na, b=\nb > > a=283, b=283
[I wrote:] > > This suggests that one could get away with "3in" as well. Yeesh. > > Not sure how I feel about that. I think I'd prefer to have Yet > > Another Warning Diagnostic for non-pristine input syntax. > > Beware of the infamous Postel principle, which has enabled many hacker > exploits and was embraced by the original definition of HTML: Be > conservative in what you write and liberal in what you accept. With > every browser having its own liberal idea, authors wrote HTML in local > cocoons, making HTMLdocuments hideously fragile. Ironically, Postel's > bad advice has been called the "robustness principle". > > In the interest of portability, I would make this a hard error, though > not necessarily one that stops groff in its tracks. We might parlay > this to a wider discussion later. 16 months later, we have it. $ printf '.nr a 3in\n.nr b 3cm\n' | ~/groff-HEAD/bin/nroff -wsyntax -z troff:<standard input>:1: warning: expected end of line or an auto-increment argument in register definition request; got character 'n' troff:<standard input>:2: warning: expected end of line or an auto-increment argument in register definition request; got character 'm' Admittedly this isn't a "hard error". GNU troff's philosophy of diagnostics seems to be that if it can't muddle through on some item of syntax, that's an error: but if it can, even if the user doesn't get what they expect, that's mere warning fodder. Still, people who turn on `-ww` will be better advised. "Isn't this a narrow case?", you may ask. "What about other places where numeric expressions appear?" Those tend to be inside escape sequences. Like so, going back as far as groff 1.22.3: $ printf 'foo\\h@3cm@bar\n' | ~/groff-stable/bin/nroff -wdelim -z troff:<standard input>:1: warning: closing delimiter does not match But I've managed to improve these too. $ printf 'foo\\h@3cm@bar\n' | ~/groff-HEAD/bin/nroff -wdelim -z troff:<standard input>:1: warning: closing delimiter does not match; expected character '@', got character 'm' There's some much more exciting stuff in Git HEAD, including some new stuff from Deri. ---snip from NEWS file--- o The `PDFPIC` macro implemented in the "pdfpic.tmac" macro file now uses identify(1) (from ImageMagick/GraphicsMagick) and file(1), if available, to attempt to determine the dimensions of an image to be embedded in a PDF document. See also the item regarding gropdf(1) below. Thanks to Deri James. [...] o gropdf(1), the PDF output driver, now allows embedding of JFIF/JPEG and JPEG 2000 image file formats. If PerlMagick is installed, many more image file formats, including PNG, PAM, and GIF can be embedded. See also the item regarding `PDFPIC` above. Thanks to Deri James. ---end snip--- Also saturating arithmetic, which I was making some noise about earlier this year. I've postponed some items from the groff 1.24.0 release goals ticket, but at this point I'm striving to get the rest done. https://savannah.gnu.org/bugs/?65099 (Scroll down to "Dependencies".) I favor feature-freezing the formatter toward the beginning of September.[1] There are 6 items affecting it left to go. Four of them should be pretty similar to each other. A fifth is, strictly speaking, a very small change (resurrecting dead warning category 4, formerly "el", as "style"), but to be useful I feel some actual style warnings should come with it. Several are already envisioned. A sixth is the "next-generation alignment/adjustment" thing I sketched out earlier this year[2]. Regards, Branden [1] With a bit of wiggle if something _has_ to change to land any of: https://savannah.gnu.org/bugs/?62830 https://savannah.gnu.org/bugs/?63583 https://savannah.gnu.org/bugs/?65098 ...for which people have been waiting VERY patiently. But at present I don't anticipate that any formatter changes being necessary beyond https://savannah.gnu.org/bugs/?63074 which is already a release goal and which I hope to have done in a week or so. [2] https://lists.gnu.org/archive/html/groff/2024-06/msg00057.html
signature.asc
Description: PGP signature
