Re: Getting our tables to render better in PDF output

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-docs@lists.postgresql.org
Date: 2020-02-13T00:56:33Z
Lists: pgsql-docs

Attachments

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Yeah, it'd look very odd, and certainly the no-parens case makes it
> worse.  I like this end result:

>> 	Function               Signature
>> 	age                    age(timestamp) → interval
>> 	now                    now() → timestamp with time zone
>> 	current_timestamp      current_timestamp → timestamp with time zone

I gave that a try, and it seems to work really well.  It can even handle
the ridiculously long signature for make_interval() in reasonable style,
as shown in the screenshot attached.

One problem with the rightarrow idea is that it's not rendering quite
right for me: it looks great in HTML, but in PDF it comes out flush
with the baseline, as you can see in the screenshot.  Hopefully
there's a way to fix that that we can hide in the custom entity ...
but I have no idea how.

I decided to try converting the date/time operators table too, to
see how well this works for that.  It's bulkier than before, but
also (I think) more precise.  I realized that this table actually
had three examples already for float8 * interval, but it wasn't
at all obvious that they were the same operator.  So that aspect
is a lot nicer here.  On the other hand, it seems like the text
descriptions are only marginally useful here.  I can imagine that
they would be useful in some other operator tables, such as
geometric operators, but I'm a bit tempted to leave them out
in this particular table.  The format would adapt to that easily.

Another thing worth considering is removing duplicate left-hand-
column entries, that is, considering all the instances of
similarly-named functions/operators to be "the same".  In the
attached patch, I did that for isfinite() but not anywhere else.
I'm not quite sure if it's a good idea or not.  It seems like it
makes sense for isfinite(), but perhaps less so for operators.

Again, comments welcome.  This is starting to feel like a real
proposal now, but I'm still not at all wedded to it.

			regards, tom lane

Commits

  1. Doc: introduce new layout for tables of functions and operators.

  2. Doc: introduce and document "&zwsp;" for allowing optional line breaks.