From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
cc: Erikjan Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org,
        pgsql-docs@lists.postgresql.org
Subject: Re: documentation pdf build fail (HEAD)
In-reply-to: <346eaf13-3b7b-c44b-07f5-d630051c8ebc@2ndquadrant.com>
References: <2e3dc9e4bfa4802d2c9f5fe15bde44de@xs4all.nl>
 <17751.1585060300@sss.pgh.pa.us>
 <346eaf13-3b7b-c44b-07f5-d630051c8ebc@2ndquadrant.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
	message dated "Tue, 24 Mar 2020 15:46:59 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14756.1585062586.1@sss.pgh.pa.us>
Date: Tue, 24 Mar 2020 11:09:46 -0400
Message-ID: <14757.1585062586@sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-03-24 15:31, Tom Lane wrote:
>> The problem seems to be that cedffbdb8
>> introduced some broken table markup.  I wonder why xmllint
>> failed to catch it?

> It's not a validity issue in the DocBook markup.  The error comes from 
> FOP, which complains because it requires the column count, but other 
> processors don't necessarily require it.

Maybe not, but if the count is there, shouldn't it be checked?

In this particular case, the table was obviously broken if you looked
at the rendered HTML, but I'd kind of expect the toolchain to provide
basic sanity checks without having to do that.

			regards, tom lane