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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jTWwP-0001sb-Q2
	for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Apr 2020 20:34:53 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jTWwO-0005ze-Cl
	for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Apr 2020 20:34:52 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1jTWwO-0005zX-5W
	for pgsql-hackers@lists.postgresql.org; Tue, 28 Apr 2020 20:34:52 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1jTWwH-0005wd-Gc
	for pgsql-hackers@lists.postgresql.org; Tue, 28 Apr 2020 20:34: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 03SKYaZV022803;
	Tue, 28 Apr 2020 16:34:36 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
        Bruce Momjian <bruce@momjian.us>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Steven Pousty <steve.pousty@gmail.com>,
        Pavel Stehule <pavel.stehule@gmail.com>,
        Isaac Morland <isaac.morland@gmail.com>,
        Pierre Giraud <pierre.giraud@dalibo.com>,
        PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Poll: are people okay with function/operator table redesign?
In-reply-to: <5561.1587922854@sss.pgh.pa.us>
References: <20200423174343.GA16996@alvherre.pgsql>
 <19233.1587665407@sss.pgh.pa.us> <5561.1587922854@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 26 Apr 2020 13:40:54 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <22801.1588106076.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Apr 2020 16:34:36 -0400
Message-ID: <22802.1588106076@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

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=3D"func_table_entry"><para role=3D"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=3D"2pt" padding-end=3D"2pt" padding-t=
op=3D"2pt" padding-bottom=3D"2pt" border-bottom-width=3D"0.5pt" border-bot=
tom-style=3D"solid" border-bottom-color=3D"black"><fo:block><fo:block marg=
in-left=3D"4em" text-align=3D"left" text-indent=3D"-3.5em">
        <fo:wrapper id=3D"id-1.5.8.9.6.2.2.4.1.1.1"><!--ceiling--></fo:wra=
pper>
        <fo:inline font-family=3D"monospace">ceiling</fo:inline> ( <fo:inl=
ine font-family=3D"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=3D"func_table_entry"><para role=3D"func_signature"><ind=
exterm>
         <primary>char_length</primary>
        </indexterm><indexterm>
         <primary>character string</primary>
         <secondary>length</secondary>
        </indexterm><indexterm>
         <primary>length</primary>
         <secondary sortas=3D"character string">of a character string</sec=
ondary>
         <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