Re: Getting our tables to render better in PDF output - Mailing list pgsql-docs

From Alexander Lakhin
Subject Re: Getting our tables to render better in PDF output
Date
Msg-id 8a99bdca-85ab-27d6-83b4-9fc7113839f2@gmail.com
Whole thread Raw
In response to Getting our tables to render better in PDF output  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Getting our tables to render better in PDF output  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-docs
Hello Tom,
12.02.2020 00:51, Tom Lane wrote:
> The crummy formatting of our tables of functions and operators has
> been an issue for a long time.  To my mind, there are several things
> that need to be addressed:
>
> * The layout is completely unfriendly to function descriptions that
> run to more than a few words.
>
> * It's not very practical to have more than one example per function
> (or at least, we seldom do so).
>
> * The results look completely awful in PDF format, because of the
> narrow effectively-available space, plus the fact that the toolchain
> will prefer to overprint following columns instead of breaking text
> where there's no whitespace.
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.

Best regards,
Alexander

Attachment

pgsql-docs by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: Duplicating website's formatting in local doc builds
Next
From: PG Doc comments form
Date:
Subject: COPY performance vs insert