Hi John, At 2026-08-01T15:05:41+1000, John Gardner wrote: > At 2026-07-26T16:40:39-0500, G. Branden Robinson wrote: > > > mandoc(1), unsurprisingly, doesn't typeset pic(1) diagrams (p. 117). > > Unfortunately because it also doesn't set a man(7) `EX`/`EE` display > > in a monospaced typeface, the fallback ASCII art is mostly > > unintelligible. > > I'm surprised mandoc(1) hasn't adopted Pikchr > <https://pikchr.org/home/doc/trunk/doc/differences.md> as a > \[open-shock-quote]✌️*mOdERn*✌️\[closed-shock-quote] alternative to > pic(1). They're even more security- and performance-conscious than > mandoc(1)'s devs are (because it does, after all, have to run > client-side in browsers to generate some potentially very complex > diagrams). Pikchr is designed to be embedded in Markdown code blocks, > like this:[1] > > ``` pikchr > arrow right 200% "Markdown" "Source" > box rad 10px "Markdown" "Formatter" "(markdown.c)" fit > arrow right 200% "HTML+SVG" "Output" > arrow <-> down 70% from last box.s > box same "Pikchr" "Formatter" "(pikchr.c)" fit > ``` > > which from a preprocessing perspective, isn't much different than a > code-block delimited by .PS and .PE macros.
Right. If someone has, or would like to prepare, a differential analysis of Pikchr's changes/extensions to to the Kernighan/GNU pic language, I would review it with great interest. I get the filling that the biggest feature gap is auto-sizing of picture elements to an associated text label, which requires the preprocessor to know the font selection and type size at rendering time, and the metrics of the font the used. It's interesting to me that the little-used and seldom remarked-upon grn(1) preprocessor already does this, and has done for over 25 years, it seems. > Pikchr is a project closely connected to SQLite, and it's used to > render railroad diagrams of SQL clause syntax. It's quite efficient, I know little of SQLite, but have had a vaguely positive impression of it to date... > though their disparaging remarks about Troff being a historically > significant but now obsolete markup language ...not so much now. > low-key pisses me off, especially knowing they implicitly mean > Markdown is Troff's "modern" replacement. Right. No field but one's own demands expertise--the mating call of the tech bro. With luck, greater maturity will seep into that project over time. > But hey, a tone of similarly-undeserved arrogance can be felt reading > mandoc(1)'s description of the Troff typesetting system or the Roff > language in general (it's more subdued, but you damn well know they > wish request-free mdoc(7) was the only macro package the world uses > and cares about). Yeah. A similar hallmark of callowness is that the problem one has selected to work on is the only one worth solving. > Anyway, Mandoc isn't a typesetting system, and it makes no allusions > to being one. I'm not even sure why they bothered with PDF output > (because it really *is* shit), Well, that's kind of my point. It _does_ make allusions to being a typesetting system by supporting emission of PostScript and PDF output. > and even its HTML output could do with some sanding, so > to speak. As groff maintainer, I dare not cast any stones here. Yet. Colin Watson, Stephen Gildea, and Nguyễn Gia Phong collectively put a boot up me backside, and while groff's HTML output still has its problems, I think it's taking a step forward in groff 1.25. See attachment. > It's great at what it does: render manual pages for terminal display > quickly and competently, I'm not completely happy with mandoc(1)'s rendering of groff's eqn(1) document. > where there isn't much wiggle-room for the > type of typography bikeshedding that leads to people arguing about the > use of fixed-pitch fonts for certain (inline) manual page elements > (which happens to be exactly what led to the creation of mono.tmac > <https://github.com/Alhadis/Mono/blob/80e8d1df113c6718406ef8a137827301ed7e1cb2/ono.tmac#L49-L79>'s > original macros for controlling how constant-width gets rendered in > terminal, if it does at all). I wouldn't classify that particular point as bike-shedding. Support for monospaced displays was a need the Bell Labs CSRC recognized all the way back in 1986. Also see one component of the aforementioned boot: https://savannah.gnu.org/bugs/?68309 But, yes, people do shed bikes in sundry other places. groff_man(7)'s "Options" section documents several. Regards, Branden
signature.asc
Description: PGP signature
