Re: Poll: are people okay with function/operator table redesign? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Poll: are people okay with function/operator table redesign?
Date
Msg-id 22802.1588106076@sss.pgh.pa.us
Whole thread Raw
In response to Re: Poll: are people okay with function/operator table redesign?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> One thing I couldn't help noticing while fooling with this is what
> seems to be a bug in the PDF toolchain: any place you try to put
> an <indexterm>, you get extra whitespace.  Not a lot, but once you
> see it, you can't un-see it.  It's particularly obvious if one of
> two adjacent lines has the extra indentation and the other doesn't.
> ...
> The only "fix" I've found is to place the <indexterm> at the end
> of the signature <para> instead of the beginning.

I spent some more time experimenting with this today, and determined
that there's no way to fix it by messing with FO layout attributes.
The basic problem seems to be that if you write

       <entry role="func_table_entry"><para role="func_signature">
        <indexterm>
         <primary>ceiling</primary>
        </indexterm>
        <function>ceiling</function> ( <type>numeric</type> )

then what you get in the .fo file is

        <fo:table-cell padding-start="2pt" padding-end="2pt" padding-top="2pt" padding-bottom="2pt"
border-bottom-width="0.5pt"border-bottom-style="solid" border-bottom-color="black"><fo:block><fo:block
margin-left="4em"text-align="left" text-indent="-3.5em"> 
        <fo:wrapper id="id-1.5.8.9.6.2.2.4.1.1.1"><!--ceiling--></fo:wrapper>
        <fo:inline font-family="monospace">ceiling</fo:inline> ( <fo:inline font-family="monospace">numeric</fo:inline>
)

where the <fo:wrapper> apparently is used as a cross-reference anchor.
The trouble with this is that the rules for collapsing adjacent whitespace
don't work across the <fo:wrapper>, so no matter what you do you will end
up with two spaces not one before the visible text "ceiling".  The only
way to hide the effects of that with layout attributes is to set
whitespace to be ignored altogether within the block, which is quite
undesirable.

The fix I'm currently considering is to eliminate the extra whitespace
run(s) by formatting <indexterm>s within tables this way:

      <row>
       <entry role="func_table_entry"><para role="func_signature"><indexterm>
         <primary>char_length</primary>
        </indexterm><indexterm>
         <primary>character string</primary>
         <secondary>length</secondary>
        </indexterm><indexterm>
         <primary>length</primary>
         <secondary sortas="character string">of a character string</secondary>
         <see>character string, length</see>
        </indexterm>
        <function>char_length</function> ( <type>text</type> )
        <returnvalue>integer</returnvalue>
       </para>

Perhaps it's only worth being anal about this in table cells with multiple
function signatures and/or multiple <indexterm>s; in other places the
whitespace variation just isn't that noticeable.  On the other hand,
there's something to be said for having uniform layout of the XML source,
which'd suggest having a uniform rule "no whitespace before an <indexterm>
within a table cell".

Or we could put the <indexterm>s at the end.  Or just ignore it, reasoning
that the PDF output is never going to look all that great anyway.

Thoughts?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Juan José Santamaría Flecha
Date:
Subject: Re: PG compilation error with Visual Studio 2015/2017/2019
Next
From: Andres Freund
Date:
Subject: Re: More efficient RI checks - take 2