From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: ** X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FROM_SUSPICIOUS_NTLD,PDS_OTHER_BAD_TLD,T_SCC_BODY_TEXT_LINE, T_TVD_MIME_EPI autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 17859 invoked from network); 29 May 2022 00:15:11 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 29 May 2022 00:15:11 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 26807dc3 for ; Sat, 28 May 2022 19:15:06 -0500 (EST) Received: from tarta.nabijaczleweli.xyz (139-28-40-42.artus.net.pl [139.28.40.42]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 9785aa3e for ; Sat, 28 May 2022 19:15:03 -0500 (EST) Received: from tarta.nabijaczleweli.xyz (unknown [192.168.1.250]) by tarta.nabijaczleweli.xyz (Postfix) with ESMTPSA id 7A1E51810; Sun, 29 May 2022 02:15:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nabijaczleweli.xyz; s=202205; t=1653783301; bh=CnKFtQQoIT/FhSmylLHgfNKD6TbPWS+NXxEOJAe+yhc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mbc2UZXLP8Gqs5+vt0luic+ps3hX+xnhU8QBRpVWxhBXbsxDltnHbmeUobahh/+aR yUIVOyAiwnRsbPdreMbJNvrACDoj0Ai4Cd3B2/WCh5MHTxETcTS1YlT5IluV3RU/Di K9SKxbsXj3dxHaj4bwU5j+jyly0w2PirHWiS2SscIyuXBPP+rYQvUlroKLlh5uGS9o g0NW5kThy/VNQDDiNkkHHqe4iMoBMG/2r1Ws2HkQP2t2qiFY0oeXczNvTsFxmD2Z6L gbXVYfOOmIMahMhvFSn9y0h1TF8o9RiRu9VkAvoiZVTtGOTxget+zZ4Ro+3HOM8P2A pMTPvrorVBhDPHCsvct7z0E72x4r3XVqd0ONKB7ZXKVdGOqZvkYIY2fG/+h0MAR+1B WiB2fIs5a+EjVx6ffCvyZpcTuuOnzwXlLCrQRkSEH37lyNgI+tjA77XsXtnags8tpe /nMbxpJ0uJ4sjRj03w0Z7LuUJaNKG9Az7/qfQL0v8XneMtV8pdBlV0uUFyyhXB3ad3 VOxpHHL4Qqq5Rge9yF3zci+jj7BsMvTGb3mJJfMri/FcEdr3BfAHA00ATNh8KVi0M7 Cm/KWVzSb7g4Ix58M+N4OpTgFH8CF8v3hd8fIX8RX+22Aglh3E5f2DSxrAPMQY+O4v 7hsH4f6PzalbBOl9puyxxyJU= Date: Sun, 29 May 2022 02:15:00 +0200 From: =?utf-8?B?0L3QsNCx?= To: Ingo Schwarze Cc: discuss@mandoc.bsd.lv Subject: Re: Getting semantically-correct mdoc fonts outside of requests Message-ID: <20220529001500.gnxuiiawdegcjwy7@tarta.nabijaczleweli.xyz> References: <20220528190313.5jdgvy57pnaqen62@tarta.nabijaczleweli.xyz> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="f7xpkcxq247jucxp" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20220429 --f7xpkcxq247jucxp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! On Sun, May 29, 2022 at 12:28:59AM +0200, Ingo Schwarze wrote: > Nab wrote on Sat, May 28, 2022 at 09:03:13PM +0200: > > This is something I've run my head into again and again while using > > tbl(7) tables =E2=80=92 since you cannot usefully execute mdoc requests >=20 > I assume you mean "mdoc macros" here. > No such thing as "mdoc requests" exists. Yes. > Except in very exceptional cases, it is bad style to use tbl(7) > inside mdoc(7). Whenever possible, use the .Bl macro instead, > preferably .Bl -tag where possible, or .Bl -column when you really > need a table with more than two columns. >=20 > If you do have a very exceptional case (that never happened to me > even though i have used mdoc(7) a lot), then keep your usage of tbl(7) > as simple as possible. All the fancy features are only implemented > for compatibility with legacy pages written in bad style. > Using macros inside tbl(7) certainly isn't simple. If you do need > macros in the table, go for .Bl, that's what it was designed for. Yes. This is why I specifically asked "how would you use mdoc macros in tbl", not "how do you make a table in mdoc" (also, notably, the groff manual disagrees: Don't abuse this list type! For more complicated cases it might be far better and easier to use tbl(1), the table preprocessor. and, indeed, it is better, because it has table decorations. Because I'm (trying to) write a table, not, as mandoc's mdoc(7) puts it, a "columnated list"). > Until support for man(7) macros inside tbl(7) gets implemented in=20 > mandoc(1), you have two options: >=20 > 1. Preferably, use the font specifiers in the tbl(7) layout, > for example: https://man.openbsd.org/tbl.7#b >=20 > 2. If for some reason, option 1 does not work, for example > because you need more than one font in the same cell, > use explicit \f escapes. This is why I didn't ask "how do you set a font". > Yes, the above both use presentational rather than semantic markup, > but that is normal for man(7) in general. Taking this as a "not possible, don't want to support". > > while in a table, I've been either hardcoding fonts or in recent > > passes doing > > .ie n .ds fAr I > > .el .ds fAr CI > > (with a preprocessing pass for mandoc which pretends to be nroff even > > when it's typesetting; >=20 > The mandoc(1) program never does real typesetting. Even the PostScript > and PDF output modes in mandoc(1) are driven by the terminal formatter. > That is why mandoc(1) always runs in nroff mode and never in troff mode. > Besides, in mandoc(1), neither -Tps nor -Tpdf support any constant-width > font. Fair, I guess. > For mdoc(7), preprocessing is useless because the mdoc(7) source > code is intended to be installed on the end-user's system, > so usually, there is no system component that could run any kind > of preprocessor. Which is why I'm /pre/processing it /before/ it's distributed. > At least for mandoc(1), you don't really want "CI" for .Ar: > * For terminal output, the "C" makes no difference. > * With mandoc(1), PS and PDF output is basically just wrapped > terminal output, so "C" makes no difference either. > * For HTML out, we have: > $ printf '.Ar foo' | mandoc -mdoc -Thtml > [...] > foo > and then in the default mandoc.css: > .Ar { font-style: italic; font-weight: normal; } > So there is no "C" either. Indeed. I had been working off my openbsd-derived stylesheet which I (apparently) modified to have .Ar be CI, not I. > Which means that if you put "CI" for .Ar inside tables, > you just make the .Ar inside the table look different > from the .Ar outside, in HTML output mode. Except that depends on the styling. Which is why I wanted to replicate the actual output you get from mandoc's mdoc package.. > > groff needs I/CI distinctions since tty output > > is 4-font only and C? fonts render as R). >=20 > What's wrong with just using \fI in n mode and \f(CI in t mode, > with both groff and mandoc, in case you absolutely insist on > mixing mdoc and tbl, which you probably shouldn't? This is what I'm doing, yes. > The style of your manual page will of course be horrible because > not only are you mixing mdoc(7) and tbl(1), but you would be > using low-level roff like \f, .ds, and .if on top of that. Which is, again, why I wanted to write this page better. To your unceasing puritan objections. > > groff's doc.tmac sets doc-??-font strings for all the semantic macros, > > such that \*[doc-Nm-font] expands to \fB under nroff > > and \f(CB (+ a font size reset) under troff, d-Pa-f to I/C, &c. > > Now, mandoc's mdoc doesn't really allow for that in a trivial fashion, > > especially in its much richer -Thtml output which doesn't trivially map > > to/from 8 fonts, but, well, that's my best attempt at prior art. >=20 > For HTML output, the whole point of mandoc(1) is writing class=3D > attributes, for example class=3DAr, and leaving font selection to CSS. At least here we agree. > So until support for mdoc(7) inside tbl(7) gets implemented in > mandoc(1), there is no way to get good HTML output from mandoc(1) > when you use words that need class=3D markup inside tbl(7) code, and > there is no workaround either. Just don't use tbl(7) in mdoc(7), > it doesn't work well and would be bad style even if it did work. Well, I've never had problems (save for this one). Ah well, =D0=BD=D0=B0=D0=B1 --f7xpkcxq247jucxp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfWlHToQCjFzAxEFjvP0LAY0mWPEFAmKSuwEACgkQvP0LAY0m WPHr4g//c5Q2bQ9wWy+Ko16z0TCQgTCCOjeG4vDp9G9JjrxhKt+kEyS8QofFrtRi TSh+Zgv+9gmFHjUV+odT1KgMKZhAX0I4hUdNU5RwDW367IGQ3WDesLTlbEP9XKK/ TqGPamLZ1s5ck9bG3stXoBPgIN9brLWnNHBbMeJ/6GyMcNNpRLy9Ilb+XGkZrBUr A5oafraWbZ81Z7wthDgchXfhU0lrq6YnjcCigoljhshHTS2M4vVsNyp8wYKosCTf sqq4zFkloTEFcZaOKBlVB2X5C8g1YPyBn/b8LCh7bOW5S+0Fv2WhGGSLQ+KFfk4e amp+gaM0uj8Kji3weJ6ukDi6oq5gWwyywyvU/rK8RcSG3K9fx0hNoZ/7efPo8H/d R+XHqISxJJfQ3n2dKY6qPEddlDwKGYjT1wT04ezyBzhF8tCUrvzRM8vmfzhSEyVP +Mi2tQ45Vg9YYeav8YOamBlR0Yr6JWs1hnMuoD94JMMgHy09B8elVdazxMevsQyM gLO6zQGBOnauF/M17KYFPILIilZs7e7aDVZS7oPddcpE9ICWMYx3tkDe4rLwAqqE BddiVnbOUnvmWJnpu+AyGrS7RkTIqUTtFr/fIc2BJs6cPIS6/g0+DoXrBtVzCppb Mfb8Ow33Xu0LoZX9IcKnL5EfIqzddXRbjY75T9/PHV0ALNJNuZ4= =6Mdh -----END PGP SIGNATURE----- --f7xpkcxq247jucxp-- -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv