From: Bruce Momjian <bruce@momjian.us>
Message-Id: <201104261732.p3QHWVn12966@momjian.us>
Subject: Re: Building PDFs error: \pdfendlink ended up in
	different nesting level than \pd
In-Reply-To: <8203.1303834211@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 26 Apr 2011 13:32:31 -0400 (EDT)
CC: Alvaro Herrera <alvherre@commandprompt.com>,
	Peter Eisentraut <peter_e@gmx.net>, Josh Kupershmidt <schmiddy@gmail.com>,
	pgsql-docs <pgsql-docs@postgresql.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Alvaro Herrera wrote:
> >> Excerpts from Bruce Momjian's message of mar abr 26 12:44:39 -0300 2011:
> >>> Alvaro Herrera wrote:
> >>>> Would it work to move only some?
> 
> >>> I think moving some would be even worse than what we have now, unless
> >>> you can propose some logic about why they would be split.
> 
> >> Remember that this thread is about someone being unable to build a PDF
> >> from our docs (and the proposed workaround being "insert more page
> >> breaks"), not about how logical the documentation is.
> >> 
> >> In any case, the ones I listed are the ones that have more structure
> >> documentation-wise (which also are the ones that have received more
> >> attention and thus are of more interest to users), so there is some
> >> logic behind it.
> >> 
> >> Am I saying that not all contrib modules are created equal?  Yes, I am.
> >> So sue me.
> 
> > It is hard to see how a user is going to guess which ones are better
> > than others when trying to find something in the docs.  I think we are
> > going to need logical categories if we want to split them up.
> 
> I don't think this works.  Aside from the illogicality, what will you do
> when somebody works a bit harder on one of the modules that have "short"
> documentation?  Push it over into the other appendix in the next
> release?  Ugh.
> 
> Unlike Bruce, I don't have any problem with pushing them all up to
> chapter level.  One point of such a change is to make them more visible,
> so I do not see it as a "disadvantage" that they'd all be visible in the
> TOC --- more the opposite.

Well, that was the original thread idea, and I don't have a major
problem with it;  I was just pointing out that it will bloat the table
of contents.  FYI, we don't currently have any headings on the table of
contents that are dynamic in that they specify items that could grow
over time.

What do you think about moving the release notes up a bit, so we have a
8.1 release notes, 8.2 release notes, and all the subreleases are under
that section?  Not sure I like that but I am throwing out the idea.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +