Hi Oliver, At 2023-04-21T20:13:14+0200, Oliver Corff wrote: > thank you very much for your encouraging feedback.
I try to moonlight occasionally from my normal gig of gripes and laments. ;-) > Indeed I did neither mention nor note in the example file (multitest.ms > --- I thought the .ms in the file name tells the story) I managed to overlook your input file name in your original mail. Perhaps the pale green contact lenses obscured my vision... > that I use groff_ms(7) as it is really at a sweet spot between > simplicity of use and aesthetics of produced document. I also think it delivers a lot of value from a fairly simple interface. We've complicated it a bit lately with an eye toward better PDF support, but if I can get a new feature or two into the formatter, I think we'll be able to take a couple of those extensions back out and do things "magically". https://savannah.gnu.org/bugs/?62264 https://savannah.gnu.org/bugs/?62787 https://savannah.gnu.org/bugs/?63074 If I'm _really_ lucky (and correct about GNU troff's internal design), then implementing the ideas above will permit the removal of the `asciify` and `unformat` requests from the formatter as well. (We would of course keep them around as macros someplace for backward compatibility.) > I remember I had used the .fam request before, at the very beginning > of a document, which always produced the desired result: the *entire* > document is typeset in the selected family. It's not too unusual to use a different font family for headers and footers. (I haven't ever seen a different face used for _footnotes_--just a change to a smaller type size--but since those are maintained in a separate environment in ms(7), it was easy enough to support such a distinction.) The driver behind the groff 1.23.0 change, which makes the FAM string more flexible, can be found in <https://savannah.gnu.org/bugs/?60422>. Long story short, one of Deri's documents brought a feature gap to my attention! > However, since this time I used .fam for the first time somewhere > within the document, I first failed to understand that, in this case, > its scope is limited to the current paragraph. This is a tentative > statement from my side, I should really test which of the .LP, .PP, > .SH, .NH etc. requests will end the effect of the .fam request. All of them (indirectly) call the internal macro `par@reset` (via `par*start` or `par*finish`), so all of them will, I think. Again, I suggest using the FAM string instead, except for small-scale typographic stunts. --snip-- Like, we're gonna have most of this sentence set in Times, .fam P but switch to Palatino right here because we're wack like that. .fam . And then go back and pretend like nothing happened. --end snip-- You will note that the `\F` escape sequence could have been used just as well to achieve the above. It's never been incorrect to break through the floor to the formatter in ms(7)--but doing so requires the user to understand the formatter and, perhaps, internals of the macro package. That would fly in the Murray Hill CSRC but not with the Unix Support Group. Lesk didn't quite rouse himself to prohibiting _anything_. The mm(7) and me(7) manuals were a bit more strident about refusing to support the arbitrary use of formatter features. > After reading your mail, I tried again to start the whole document with > the .fam Libertine request, et voilà, the whole document is typeset in > the chosen font family. I'm glad it worked out! I do think .ds FAM Libertine ...would be more robust, though. :) > Thank you very much for the hint regarding .fam, And I wanted to compliment you on your document. It is _exactly_ the sort of thing I had in mind when I went to the (surprisingly troublesome) effort of refactoring localization support to make English and its hyphenation patterns merely a default as opposed to something bolted more firmly into the system. I had visions of people switching between multiple languages smoothly, with appropriate hyphenation patterns being loaded and unloaded, and the document author never having to do more than source the requisite localization macro file. There is still a feature gap; I still want a `hydefault` register. https://savannah.gnu.org/bugs/?63635 Lacking it isn't fatal--we've gotten along all these years without it. But for limited domains like man pages--where localized pages are a thing, but switching natural languages within a document is practically unheard of--people do, despite our warnings, reach down to the udder of the formatter and start grasping at appendages like `hy`, it could prevent some problems that would be frustrating to debug. And, to be frank, there were flaws in Ossanna's troff. There were multiple aspects of formatter state that should have been visible but, originally, weren't. The current adjustment and hyphenation modes are two examples. The `.j` register didn't show up until Kernighan's rewrite, and it took groff to expose `.hy`. A further problem was the non-orthogonality of state restoration across requests. The `ft`, `ps`, and `in` requests, among several others, went back to the previous state if given no arguments. But `ad` didn't,[1] and `hy` without an argument always selected hyphenation mode "1". (Alignment and adjustment were also unhelpfully conflated.) Iconoclastically yours, Branden [1] This is left-aligned text. .br .ad c This is centered text. .br .ad Now we're back to left-aligned.\|.\|.hey, wait!
signature.asc
Description: PGP signature
