Re: Getting our tables to render better in PDF output

Corey Huinker <corey(dot)huinker(at)gmail(dot)com> writes:
> On Mon, Apr 13, 2020 at 12:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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