Re: Poll: are people okay with function/operator table redesign?
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2020-04-26T17:40:54Z
Lists: pgsql-hackers
Attachments
- markup-revision-test.patch (text/x-diff) patch
- website-markup-hack.patch (text/x-diff) patch
- table-9.9-old-markup.png (image/png)
- table-9.9-new-markup.png (image/png)
- table-9.9-new-markup-pdf.png (image/png)
I wrote: > Alvaro Herrera <alvherre@2ndquadrant.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
Commits
-
Doc: re-re-revise markup for tables of functions.
- 4ad047a6eac3 13.0 landed
-
Doc: revise formatting of function/operator tables.
- 737d69ffc3cf 13.0 landed