From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 9bc3306b for ; Mon, 20 May 2019 00:50:42 -0500 (EST) Received: by mail-pg1-f169.google.com with SMTP id 145so6206933pgg.9 for ; Sun, 19 May 2019 22:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cathet-us.20150623.gappssmtp.com; s=20150623; h=sender:from:to:subject:mime-version:content-id:date:message-id; bh=yfOI+YAnNec0sxd046DQStt8GhReIDAp3fYGWJit4zo=; b=Ftg/TBYfowIt/KHo/JSInWENcP9U0UcpWffYPwFuRsvU6N62V7qznn6TyvYQ9uxIyO 1qGPDHv+MmUh9Yp2GgPnzg1SFbg0QGuVSj6k8frun5+HObMK8V8fJQpUawBvvKTLugvG o4u7cJUfTdx4RqLbeE4nMh5JY6DMxznbT7oyVPbKbH96jwGFvp5kSb/2FxolNZhv9dNz 2HF8NpTHmLAUDa+MNXQ2EiR+eYPzEcPZJh0WOKH5+4NnAzN7cuYhyWcls30Jx9juPDBH 7BYv5bcPTy+dDw4SPHtXpgSswbTBY68qSQdTRZ2bnapn2Ee2iqlSMereaSCXIHPrARL2 vBGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:mime-version:content-id :date:message-id; bh=yfOI+YAnNec0sxd046DQStt8GhReIDAp3fYGWJit4zo=; b=B3UcGxOUygSdbsgTohHrxGpSp+dVvbRUTiXsquQ4Tmfd5Dqzf2c+aXHhuCDkq5RYsM lRyhMyeaoxFBtvKIxmWTyVa00E+g5J0EzR1ucZ/jRyuz2H1rhSxVGFa+jlnCmiNraG3f heBPDi6Yudkkju5/Q/JqvBsq/iAtuVkginbOZN8ktacqrU3GjVA+mMPhL2/R8skBw8Lc 2Vja+GYOIOOO+AWGCoE5ARIjFvfoNpftcGnjXzofYaLAt0HgTfaFqxE/4YP4RVoScotg JAoOkrKvJnJBeyIsWM9dq6h87X8O/QZqXxzCjeDo/picIzxB5fH2KUgN7zDvKtCeFoJg U/fg== X-Gm-Message-State: APjAAAUhjDtauQm8PSJKdXB9jM9TVrEbunFkNx9Cen05TaCDcEJmRj2t J5sArCXaq2FDlJ+jh5iYPetkfxZMGI0= X-Google-Smtp-Source: APXvYqyQEAYVPyZKBund/xgP7OO6vwwdz/A0BUtqd8d8XQJ2HMsQrvW1CWFEzkD+2evXGlY2BcuipQ== X-Received: by 2002:a63:295:: with SMTP id 143mr73158952pgc.279.1558331440957; Sun, 19 May 2019 22:50:40 -0700 (PDT) Received: from desktop.ajb.soy (75-161-114-94.albq.qwest.net. [75.161.114.94]) by smtp.gmail.com with ESMTPSA id n21sm14352268pff.92.2019.05.19.22.50.39 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 19 May 2019 22:50:40 -0700 (PDT) Sender: "Anthony J. Bentley" Received: from desktop.ajb.soy (localhost [127.0.0.1]) by desktop.ajb.soy (OpenSMTPD) with ESMTP id b3437dd3 for ; Sun, 19 May 2019 23:50:38 -0600 (MDT) From: "Anthony J. Bentley" To: tech@mandoc.bsd.lv Subject: docbook2mdoc and [sub]section links X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <57435.1558331438.1@desktop.ajb.soy> Date: Sun, 19 May 2019 23:50:38 -0600 Message-ID: <9061.1558331438@desktop.ajb.soy> Hi, Instances of .Sx that docbook2mdoc(1) generates in text don't match the case of the actual section name. The Sx's printed text (and, in HTML output, the href of the hyperlink) will come from the section's id in the DocBook source, which is not correct. For example, here's a sample from the DocBook source of fonts(7): This document describes the support for fonts in X11R&relvers;. is aimed at the casual user wishing to install fonts in X11R&relvers; the rest of the document describes the font support in more detail. (snip) Installing fonts And the result currently in xenocara: This document describes the support for fonts in X11R6. .Sx Installing_fonts is aimed at the casual user wishing to install fonts in X11R6 the rest of the document describes the font support in more detail. (snip) .Sh INSTALLING FONTS The Sx line should match its Sh, "INSTALLING FONTS". A related problem is with . docbook2mdoc(1) generates Sy in Pp for the tag. While dissatisfying, I don't know what better solution there could be at the moment. But since this can't be treated as a normal section cross reference, docbook2mdoc(1) should not create Sx for references to . An example: All that remains is to tell the X server about the existence of the new font directory; see below. (snip) Setting the server's font path becoming: .Pp All that remains is to tell the X server about the existence of the new font directory; see .Sx Setting_the_servers_font_path below. (snip) .Pp .Sy Setting the server's font path -- Anthony J. Bentley -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 651f63b8 for ; Mon, 20 May 2019 12:45:09 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1hSmLT-0000oz-A4; Mon, 20 May 2019 19:45:08 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1hSmLS-0002Jx-Cz; Mon, 20 May 2019 19:45:06 +0200 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1hSmLS-0006oK-8P; Mon, 20 May 2019 19:45:06 +0200 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 89114085; Mon, 20 May 2019 19:45:06 +0200 (CEST) Date: Mon, 20 May 2019 19:45:06 +0200 From: Ingo Schwarze To: "Anthony J. Bentley" Cc: tech@mandoc.bsd.lv Subject: Re: docbook2mdoc and [sub]section links Message-ID: <20190520174506.GA53563@athene.usta.de> References: <9061.1558331438@desktop.ajb.soy> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9061.1558331438@desktop.ajb.soy> User-Agent: Mutt/1.8.0 (2017-02-23) Hello Anthony, Anthony J. Bentley wrote on Sun, May 19, 2019 at 11:50:38PM -0600: > Instances of .Sx that docbook2mdoc(1) generates in text don't match the > case of the actual section name. The Sx's printed text (and, in HTML > output, the href of the hyperlink) will come from the section's id in > the DocBook source, which is not correct. Yes, this is a known shortcoming. The proper fix involves: 1. During parsing, building a table of ID attributes. 2. During parsing, record the (and possibly similar) attributes as-is. 3. In a later validation phase (after parsing), iterate all nodes an change those pointing to ID attributes to point the titles associated with the ID attributes. So far, i shied away from doing that because it is slightly complex. But it needs to be done at some point. > A related problem is with . docbook2mdoc(1) generates Sy in Pp > for the tag. While dissatisfying, I don't know what better solution > there could be at the moment. But since this can't be treated as a > normal section cross reference, docbook2mdoc(1) should not create Sx > for references to . Thanks, i wasn't aware of that aspect yet. You are right that mdoc(7) simply doesn't support a third level of sections - which is more a feature than a bug, avoiding excessive complexity of documentation. I agree that in such a situation docbook2mdoc(1) should just not generate the .Sx macro. That requires selectively adding entries to the ID table, then deleting cross references during the validation phase when there is no match for the target. This is all a bit on the more tedious, lower priority side of features to implement, yet it should clearly be done. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv