From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id +OXQKENO9GVFDwEA62LTzQ:P1 (envelope-from ) for ; Fri, 15 Mar 2024 14:33:55 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id +OXQKENO9GVFDwEA62LTzQ (envelope-from ) for ; Fri, 15 Mar 2024 14:33:55 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=smtpauto.stravinsky header.b="KWfI/vyp"; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710509635; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=s6iS2A1Rk6wktEXgc/eXCfe7jJZ8ZgsTYiWcdDrpBSo=; b=IlGWyNkT+XtyRRPHJFnkjo9ww0xPTMfLtbyfDKXDG8v/mu/dxXSkB6+xi3amcgIjEmTXgB bY/nIiVOleClyvV0s4D0ORpFFmBfj1HDgETEqJ1oyKJdeyK2Oz6AykCSpqoT7GVYzYII44 peQ/e+eyVc9iarMMa9UBIwGfnXyxN4bivINIu3q9OnuIxuIAaqYxmFm9rfbG7Eh7rNoi2i vILMeqeZuRjAyxSqEaMji0ZWIPIVEH2WRY0GKsOhQ7TdFcAb547SW/JqxeItp17FfcWwYQ NHkpcD6CDGifcWq2gQgJK+3CTtYeTtgfXG2Y40jPTHjktsrNKM1idoRoQPhSiA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1710509635; a=rsa-sha256; cv=none; b=n7lSQVpQQZ7BXBo6UNJldfNs4AnV3MGPtxEiz3FCujQJYwZOGMp2lvtGqhkOeEIwoPD2Ih koNh4xWl3kKIKdXmHFNknVqTZSAq7zSutVF8EfKbCqReiAs03aZjQFpwW9kIXH2Nx9Hyue B3utPrkj3hAFobO1cBnoWPUnsgXWGoV9dbAHy3LMl148Ky3ly52HEeIVCDHPlCU07O46MJ TCSp4K41wOmqYKUGK3/aZHO6OeW3wk1HZkuE8w47Hberhf5+7ji6g9D56lXq2Q0fqDJDYH oJlXLL8wjqKdMQj3G7ysZAPHFqcNjY5HqijXrdkTFBKpr4Amj+A82IE2gmeSKg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=smtpauto.stravinsky header.b="KWfI/vyp"; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C71976B64E for ; Fri, 15 Mar 2024 14:33:54 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rl7gS-0003pF-A7; Fri, 15 Mar 2024 09:33:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rksuq-0005av-Ep for emacs-orgmode@gnu.org; Thu, 14 Mar 2024 17:47:08 -0400 Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rksuo-0001C6-FA for emacs-orgmode@gnu.org; Thu, 14 Mar 2024 17:47:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=s6iS2A1Rk6wktEXgc/eXCfe7jJZ8ZgsTYiWcdDrpBSo=; b=KWfI/vypmmIPLv91n07A3pw+HN Zd31fETzF9972bbJZedgylQ0rskzT/Nz1DulAWCxefCD4KBk4vD++jBCyzewPv0qG+Fl0LUQE+VjW I0BRGRRNCyJeOxfll6sPzQ9nte00sCMUGDNBWFfCT3e2/n37mjnDPrvgBSMYl+ebUrk/YHK0zVaT+ AEzllQor1EC/LsJz/u/NrRoBgwEOzcJd/qnJ9iRBM3R4xjmcVh1Ie7M39mZ5D0jAwKnyOu6Io1jp7 Jp9cnFeSTEoNUuVb6tm3DUjllaY8e5Lody4PFRucz9O2LkEy5qNJBnxFRQmNJejICWLNWjgTHyU2G c4CNoXww==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1rksuc-00CMLc-GE; Thu, 14 Mar 2024 21:46:55 +0000 Date: Thu, 14 Mar 2024 21:46:51 +0000 From: Jeremy Sowden To: Ihor Radchenko Cc: Xiyue Deng , emacs-orgmode@gnu.org Subject: Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)] Message-ID: <20240314214651.GB324558@celephais.dreamlands> References: <87v866jsou.fsf@debian-hx90.lan> <87frx7moh8.fsf@localhost> <87h6hcia9y.fsf@debian-hx90.lan> <878r2mxtjw.fsf@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G5zRtFZXh0+ZSB9p" Content-Disposition: inline In-Reply-To: <878r2mxtjw.fsf@localhost> X-Debian-User: azazel Received-SPF: none client-ip=2001:41b8:202:deb::311:108; envelope-from=azazel@debian.org; helo=stravinsky.debian.org X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.987, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 15 Mar 2024 09:33:14 -0400 X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -13.71 X-Spam-Score: -13.71 X-Migadu-Queue-Id: C71976B64E X-Migadu-Scanner: mx11.migadu.com X-TUID: hXL2kCKtKCJo --G5zRtFZXh0+ZSB9p Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2024-03-13, at 11:25:23 +0000, Ihor Radchenko wrote: > On 2024-03-11, at 17:06:17 -0700, Xiyue Deng wrote: > > Ihor Radchenko writes: > > > Xiyue Deng writes: > > > > (This was first reported to Emacs at > > > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D69483) > > > > > > > > "mu4e"[1] (a popular Emacs mail client) uses Org to generate its > > > > manpages. However, the generated output contains macros that > > > > are not understood by groff. After some debugging, Jeremy > > > > traced this back to the macro "\fC" used in ox-man.el[2]. Git > > > > history shows that this may have been there since the beginning. > > > > We tried to find a documentation for the "\fC" macro but has not > > > > been able to find one. Jeremy suggests that "C" may be an old > > > > alias for Courier, and if that's the case it should be changed > > > > to "\f[CR]". Would be great if Org people can confirm. > > > > > > This is not an unknown problem. AFAIU, the \fC macro is widely > > > used for troff, although it is not supported by groff. Check out > > > the ongoing discussion at > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1049968#15 > > > > > > They suggest the following instead of \fC: > > > > > > The best solution known to me is to use an extension to the > > > man(7) language. It first appeared in Ninth Edition Unix > > > (1986) and was adopted by a groff release in 2009. That is the > > > `EX`/`EE` macro pair, which sets a monospaced display. (In > > > other words, filling is disabled and a monospaced font selected > > > if necessary.) Thanks for the pointer. Mildly embarrassed that I didn't find this when I was doing the initial triage in Debian. :) > > I'm not very familiar with roff so my understanding may be off. > > According to the `Safe subset' section in man(7), they mentioned the > > following: > > > > ,---- > > | Font changes (ft and the \f escape sequence) should only have the > > | values 1, 2, 3, 4, R, I, B, P, or CW (the ft command may also have no > > | parameters). > > `---- > > > > Does it mean `\fC' should be replaced by `\f[CW]'? > > I am not sure > > man 7 groff has > > Fonts often have trademarked names, and even Free Software fonts > can require renaming upon modification. groff maintains a > convention that a device=E2=80=99s serif font family is given the n= ame T > (=E2=80=9CTimes=E2=80=9D), its sans-serif family H (=E2=80=9CHelvet= ica=E2=80=9D), and its > monospaced family C (=E2=80=9CCourier=E2=80=9D). Historical inertia= has driven > groff=E2=80=99s font identifiers to short uppercase abbreviations of > font names, as with TR, TB, TI, TBI, and a special font S. > > So, \fC refers to "Courier". > > I did not find any text description of CW font, but my groff > installation has usr/share/groff/1.23.0/font/devdvi/CW font spec: > > name CW > special > ... > > for comparison, /usr/share/groff/1.23.0/font/devps/CR has > > name CR > internalname Courier > ... > > which looks more suitable. But CR is not listed in "safe" subset (man > 7 man) > > Also, neither CW nor CR work with html output: > > with \fC > > .TH "" "1" > .PP > \fBThis is test\fP > \fCcode a+b\fP here a+b. > > yields (groff -Thtml test.man) > >

This is test code a+b here a+b.

> > Note tag. > > but with \f[CW] > > .TH "" "1" > .PP > \fBThis is test\fP > \f[CW]code a+b\fP here a+b. > >

This is test code a+b here a+b.

> > No special markup is applied to the code. > > Same for \f[CR]. > > > Also CCing Jeremy who may have a better idea on how this should be > > handled. What I did for the mu4e man-pages was to patch them to alias font C to B: .ftr C B My initial assumption when I first looked into this is that the font to use would be `CR`, not `CW`. Doing this with `CR` does seem to work: $ cat /space/azazel/tmp/test.man=20 .ftr C CR .TH "" "1" .PP \fBThis is test\fP \fCcode a+b\fP here a+b. $ groff -Thtml /space/azazel/tmp/test.man | tail -5 | head -2

This is test code a+b here a+b.

However, as you observe, `\f[CR]` doesn't (nor does `\f(CR`). I note that groff's HTML support is stated in the grohtml(1) man-page to be in beta. Haven't checked the source to determine whether that is what's going on here. In any case, my understanding from reading the conversation in the Debian bug-report is that this issue affects multiple roff generators in Debian. Therefore, it probably makes sense to consult within Debian before asking the maintainers of those generators to make changes. I need to go over that conversation again and think about this more. J. --G5zRtFZXh0+ZSB9p Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEbB20U2PvQDe9VtUXKYasCr3xBA0FAmXzcEMACgkQKYasCr3x BA3dlBAAsKBQ8bMmLLGqiHzWfev32QrUcU5iiMAw8Sm5ICi76+xpApBIxKZ0V4kY StzJ5Hsfbl+MNfmiW+yTZzSCF6advxGCdznYpka89m/WSKyDFay++hTY618e2WxB 7uWwcmBgs5vreH88OPrr9Ryq01WIwyNrvpeeSRd8o7BAxmQ9uNXr7x8glj8ShcSe aX6b1Ql+KfZc2kml276NG3SImMMrJGeWwfd1GfQmjidOZRzllolRAHPQZkzE89EV BZdSegePusn99sRjdrnS8vnjn0KR0TZlZUzVkai9UDfdyDcxb9JFbYgb2IeVegFJ py8RVPMjRJDiAvEna7DLes0Z99Mm1Ph0yLYCDsuYB6eaGETw9dqYA4svTTgJd/PI bBJRU5sOo1AGbOZqglGLQvvY2LmoT0dtzMBg41yJwg+5fmRt8/XPFwTZYvKueInC fzww8lkcYTL/P7SQsszbgwy0k5hMqVta2N7+QcAExRPQ0Ni9cKxs1ykUuwKMMLbi DlNi1gbYKbGxToS72aRjYcnvFuPaV8KTnGZarMQSYubZDBbNZb47V+67jhbMpau9 NzE2o3MI4lLS0xESQb5Pj4FcC6g8A2x7HNsdf0y8hSiPgcp0LQIaQR5PYfYZ3jYX giu1KNeWPybYnpD3SOrrtyyFn+0nYTqQ8YgKnx7Zn+wLsBPTIio= =cZ2Q -----END PGP SIGNATURE----- --G5zRtFZXh0+ZSB9p--