Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jO4KE-00010F-Pi for pgsql-docs@arkaria.postgresql.org; Mon, 13 Apr 2020 19:00:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jO4KC-0005TD-WC for pgsql-docs@arkaria.postgresql.org; Mon, 13 Apr 2020 19:00:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jO4KC-0005SH-QM for pgsql-docs@lists.postgresql.org; Mon, 13 Apr 2020 19:00:52 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jO4KA-0007Yn-LD for pgsql-docs@lists.postgresql.org; Mon, 13 Apr 2020 19:00:51 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 03DJ0mvC013741; Mon, 13 Apr 2020 15:00:48 -0400 From: Tom Lane To: Corey Huinker cc: Alexander Lakhin , pgsql-docs@lists.postgresql.org Subject: Re: Getting our tables to render better in PDF output In-reply-to: References: <20200212221818.GA15503@alvherre.pgsql> <23574.1581555393@sss.pgh.pa.us> <10810.1581883655@sss.pgh.pa.us> <5d1f5b72-1b4a-6e15-6730-d94e2252a073@gmail.com> <525a6c9e-a4e2-cd8f-54b6-b69f40d70289@gmail.com> <701.1586638307@sss.pgh.pa.us> <6162.1586644916@sss.pgh.pa.us> <10438.1586752582@sss.pgh.pa.us> <6694.1586795337@sss.pgh.pa.us> Comments: In-reply-to Corey Huinker message dated "Mon, 13 Apr 2020 14:39:41 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13739.1586804448.1@sss.pgh.pa.us> Date: Mon, 13 Apr 2020 15:00:48 -0400 Message-ID: <13740.1586804448@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Corey Huinker writes: > On Mon, Apr 13, 2020 at 12:28 PM Tom Lane wrote: >> I'm not really buying into that as a requirement. For one thing, the >> anchor name will be 100% predictable. > The anchor name is deterministic (or I intend it to be) but > the existence of the link is not predictable. So while having no visible > link is fine for internal links which we create, I'm envisioning a > not-very-experienced reader wanting to help an even-less-experienced > person. If they find the date_part function, and they see that the word > "date_part" is itself clickable, they'll probably click it once, see that > it's a link, and send the less-experienced person the anchored link instead > of the broader page link. They're very unlikely to try to forge their own > anchor link in the hopes that it already exists. Meh. I think people are going to think that a link that points at itself is pretty silly. Now, if the link appearing in the index were precise, people might copy that one and use it ... BTW, I just noticed that the way that the index is rendered on the website is beyond awful. The sub-items of an index entry are left-justified instead of being indented as they ought to be (and are, if you build the docs locally without using the website style). This makes it look like the sub-entries are main entries which is totally confusing. Can somebody fix that? regards, tom lane