Re: Getting our tables to render better in PDF output

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> Please look at a less invasive approach that we use at Postgres Pro for
> some time (mainly for improving the translated documentation, but it
> works for the original one too). The idea is to add zero-width spaces
> after/before some chars ('(', ',', '[', etc) to let fop split lines
> where desired. It has one disadvantage - it's not search-friendly
> (though maybe that is application-dependent).
> But if it's feasible, I think this approach can at least complement a
> manual tables reformatting. Decreasing a font size in the tables seems
> appropriate to me too.

Hmm, interesting proposal. I experimented and verified that injecting
zero-width space (&#x200B;) does allow line breaking to occur in both
HTML and PDF output, so this could be a route to improving the situation
for overlength example texts. I do not think I like the idea of
automatically injecting tons of them, though. As you say, it might
hinder searching; and it would allow some silly breaks; and there are
cases where it still wouldn't find a break, such as the examples for
sha256() et al. I'd be happier about manually inserting breaks just
in the places we really need them. To keep the source readable, I'd
want to write something like "&zwsp;" not a numeric entity code,
but it looks like we can define custom entities if we want.

For amusement's sake, attached is a screenshot of what Table 9-33
looks like in A4 format, with my one-row-per-example patch of
yesterday plus a few manually-added zero-width spaces to break up
the examples. This is the first PDF rendering of that table that
I've seen that I actually like.

I also attached a screenshot of a segment of Table 9-31, to show
what that layout proposal looks like. It's a little busier, but
it does have the advantage that it's clearer how to apply that
format to operator tables. The "returns <type>" notation isn't used
anywhere in SQL for operators, so I am not in love with the idea of
writing the operator tables that way.

Also worth noting is that in most function tables, and certainly
in the operator tables, we could make the first column narrower.
The same table with the first column half as wide as the others
is depicted in the last screenshot. (For this particular table,
doing that would require breaking some of the longer function
names such as transaction_timestamp. Not sure whether that's
a net win, but we do have the option.)

One issue that I've found is that the toolchain has no idea that
the table rows are in groups, so it's happy to split a table
across pages with a function's description and/or examples on
a new page. No idea if there's any way around that. Fortunately
it's not an issue in HTML, so maybe we don't have to fix it.

Thoughts?

regards, tom lane