Hi Deri, At 2024-10-09T16:08:58+0100, Deri wrote: > On Wednesday, 9 October 2024 12:57:47 BST G. Branden Robinson wrote: > > Maybe I felt like somebody who just endured a blitz of 1,000 > > warnings... > > > > troff:./utp_ix.t:4034: warning: cannot select font 'CW' > > > > ...that he didn't care about. 😅 [...] > I noticed you fixed it by adding:- > > .ftr CW CR > > To utp.mac, which happens to be exactly the same as the line removed > from ps.tmac in commit 1d8452fb, rather than adding -Wfont to the > Makefile (which you have previously suggested), so you must have > realised this was not just a warning, but also affected rendering of > documents as well.
Of some documents. Yes, I did. > This commit is the sort of change which I think requires some sort of > deprecation before the final change. It's hard to deprecate this. I gave some thought to it. We have no logic in the formatter that "hooks" on font identifiers. There isn't a way to replace a font identifier dereference with a macro (or anything like a macro) that checks some bit of formatter state and then can throw a warning. If we did, that would be general enough to be useful, at least for situations like this. The other approach that occurred to me was to extend the formatter's font class to support some kind of deprecation bit. But then we'd need requests to set and unset it. Here's a straw-man example. .\" ps.tmac .ftdeprecate CW 1 .\" New macro file: att.tmac .\" -matt: "Just shut up and render my old AT&T troff document!" .ftdeprecate CW 0 .ftr CW CR It feels _really squicky_ to me to add a whole new request to the formatter just infrastructural support for the deprecation of something else. It doesn't seem worth it. Both of the above approaches involve formatter/C++ changes, and while I've blown my deadline for such things, the day is getting late for such stuff for 1.24. I guess maybe we could have the "att.tmac" file without the `ftdeprecate` feature (once remapped, the font name "CW" wouldn't actually be dereferenced in the first place), but then people would _still_ have to change their workflow to add a new "-matt" argument, and if we're disturbing them that much already, then a diff like the one you noted: https://github.com/g-branden-robinson/Unix-Text-Processing/commit/5a5fa35f4fb914a3ef900ea9ed7bfa4976ef384d diff --git a/src/utp.mac b/src/utp.mac index ab40da9..b566fd8 100644 --- a/src/utp.mac +++ b/src/utp.mac @@ -10,6 +10,9 @@ book available again. Version of 16 November 2002 .. +.ftr C CR +.ftr CW CR +.ftr H HR .RT .nr nH 0 \" don't number [ABCD]-heads .nr gE 0 \" don't add chapter number to [ABCD]-heads ...seems like just about the same amount of effort _and_ has the further benefit of being portable to every groff release ever. (N.B., I didn't guard the `ftr` requests with `do` because the UTP project assumes outright that it's being formatted with groff; our extensions are employed ubiquitously. But that is probably what one would do in the hypothetical scenario above.) > If the warning was about the AT&T fontnames being deprecated but no > change to the font used (i.e. continue to use CR), even though there > would be 1000+ warnings, it would achieve your desire to drop support > for the ancient font names but in a way which did not affect rendering > of the document in the interim. What do you suggest instead? Regards, Branden
signature.asc
Description: PGP signature
