Re: Getting our tables to render better in PDF output
От | Tom Lane |
---|---|
Тема | Re: Getting our tables to render better in PDF output |
Дата | |
Msg-id | 13740.1586804448@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Getting our tables to render better in PDF output (Corey Huinker <corey.huinker@gmail.com>) |
Список | pgsql-docs |
Corey Huinker <corey.huinker@gmail.com> writes: > On Mon, Apr 13, 2020 at 12:28 PM Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-docs по дате отправления: