Re: Getting our tables to render better in PDF output

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: Getting our tables to render better in PDF output
Date: 2020-02-12 04:05:06
Message-ID: 8a99bdca-85ab-27d6-83b4-9fc7113839f2@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
fix-pdf-overflow.patch text/x-patch 5.9 KB

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Corey Huinker 2020-02-12 04:22:43 Re: Add A Glossary
Previous Message Jonathan S. Katz 2020-02-12 03:56:27 Re: Duplicating website's formatting in local doc builds