public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bruce Momjian <[email protected]>
To: Tom Lane <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Josh Kupershmidt <[email protected]>
Cc: pgsql-docs <[email protected]>
Subject: Re: Building PDFs error: \pdfendlink ended up in different nesting level than \pd
Date: Tue, 26 Apr 2011 13:32:31 -0400 (EDT)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

Tom Lane wrote:
> Bruce Momjian <[email protected]> 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  <[email protected]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

view thread (26+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Building PDFs error: \pdfendlink ended up in different nesting level than \pd
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox