From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Getting our tables to render better in PDF output |
Date: | 2020-02-14 21:06:51 |
Message-ID: | 6309.1581714411@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2020-Feb-13, Alexander Lakhin wrote:
>> Third (minor) issue is with translation - when I will see some break in
>> the English source, e.g. "split_part('abc~(at)~def&zwsp;~(at)~ghi', '~(at)~',
>> 2)", should I leave the break in the same place, or it's better to move
>> it because adjacent text has different length and the table columns have
>> different width?
> If the English version is warning-clean, then it should be possible to
> keep the zwsps in the same location in the translation, and then tweak
> the translation according to any new warnings that appear there.
> My guess is that the majority of zwsps are going to want to stay in the
> same place.
So far as I've seen, the majority of places where we'll still need to
insert break opportunities are in examples and example results, which
don't seem like they'd be subject to translation. I'm really not eager to
turn loose an automatic-zwsp-inserter for a problem that might be mostly
hypothetical once we have a more forgiving table layout in place.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2020-02-14 22:43:57 | Re: Duplicating website's formatting in local doc builds |
Previous Message | Alexander Lakhin | 2020-02-14 21:00:00 | Re: Getting our tables to render better in PDF output |