Re: Poll: are people okay with function/operator table redesign?

I wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> If we're doing nicer markup+CSS for this, then it might make sense to
>> find a better solution for this kind of entry with multiple signatures
>> (which was already an issue in the previous version):

> Yeah, agreed. I would like to be able to have multiple signature blocks
> in one table cell, which the current hack can't handle. There aren't
> quite enough cases to make this mandatory, but it would be nicer.
> It seems do-able if we explicitly mark signature blocks with their
> own role, say ...

Hearing no comments, I went ahead and experimented with that.
Attached is a POC patch that changes just the header and first few
entries in table 9.9, just to see what it'd look like. This does
nicely reproduce the existing visual appearance. (With the margin
parameters I used, there is a teensy bit more vertical space, but
I think it looks better this way. That could be adjusted either
way of course.)

There is a small problem with getting this to work in the webstyle
HTML: somebody decided it would be a great idea to have a global
override on paragraph margin-bottom settings. For the purposes of
this test I just deleted that from main.css, but I suppose we want
some more-nuanced solution in reality.

<digression>

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.
In the attached, I added an <indexterm> to one of the signature
entries for "text || anynonarray", and you can see what I'm unhappy
about in the PDF screenshot. The problem already exists in our
previous markup, at least in places where people put indexterms
inside function-table entries, but it'll be more obvious anyplace
we choose to have two signature entries in one table cell.

I tried putting the <indexterm>s outside the <para> elements, but
that makes it worse not better: instead of a little bit of extra
horizontal whitespace, you get a lot of extra vertical whitespace.

The only "fix" I've found is to place the <indexterm> at the end
of the signature <para> instead of the beginning. That's not included
in the attached but it does hide the existence of the extra space
quite effectively. I'm not sure though whether it might result in
odd behavior of cross-reference links to the function entry.
In any case it feels like a hack.

</digression>

It seems to me that this way is better than the markup I've been
using --- one thing I've observed is that Emacs' sgml mode is a
bit confused by the <?br?> hacks, and it's happier with this.
But it's not clear to me whether this is sufficient to resolve
Peter's unhappiness.

regards, tom lane