Re: Getting our tables to render better in PDF output

On Sun, Apr 12, 2020 at 8:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Corey Huinker <corey(dot)huinker(at)gmail(dot)com> writes:
> > On Sat, Apr 11, 2020 at 6:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Is that going to be a problem for the docs toolchain? If
> >> the anchors are attached to individual function names rather than
> >> sections or paragraphs, do they actually work well as link references?
> >> (I'm particularly wondering how an <xref> would render.)
>
> > So I can't speak to any scalability issues for adding a bunch of refs,
> but
> > I did try this out for justify_days() (diff attached) and here's what I
> > found:
> > * <link linkend="function-justify-days">justify_days</link>
> > This made a link, in the same font as any other link ref.
> > * <xref linkend="function-justify-days"/>
> > This made a link that looks exactly like the previous one, with the
> text
> > "justify_days", so if we're fine with the font change, we could use that
> > * <link
> > linkend="function-justify-days"><function>justify_days</function></link>
> > This made the link we want in the function font.
>
> Hm. Attaching the link ID to an <indexterm> is an interesting hack.
>

it worked for glossterms, I figured an indexterm is just another 'term.

> My inclination is to standardize on using <xref> for references and
> just accept the lack of a special font. It's not worth the notational
> pain to use both <link> and <function>, especially not in HTML output
> where links will probably get rendered specially anyway. We
> previously made the same tradeoff with respect to GUC variables,
> and I've not seen many complaints. (I experimented with putting
> <function> into the indexterm text, but that did not help.)
>
> I'd be a bit inclined to shorten the ID prefix to "func-", just
> in the interests of carpal tunnel avoidance.
>

xref it is. I'll take a shot and scripting the necessary changes.