public inbox for docbook-tools-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Eric Lee Green <elgreen@iname.com>
To: Peter Toft <pto@sslug.dk>, docbook-tools-discuss@sourceware.cygnus.com
Subject: Re: Book split to several books
Date: Wed, 27 Dec 2000 06:36:00 -0000	[thread overview]
Message-ID: <00071511261800.24882@ehome.inhouse> (raw)
In-Reply-To: <Pine.LNX.4.21.0007151938470.855-100000@laptop.linus.dk>

On Sat, 15 Jul 2000, Peter Toft wrote:
> Now I have to split the book into 4-5 parts, but I like
> feedback on how to do this in an optimal way. My
> problem is that I have many cross-references which will
> suffer from the split. 
> 
> I have looked into using <part> which presumably
> enables me to keep correct cross-references, but I
> really would like to compile the sub-books
> individually now - currently it takes too much time to 
> make PS, PDF, and HTML.

Unfortunately your two goals (seperate compilation, extensive cross-references)
are incompatible. Splitting your document into parts or multiple files on disk
is easy enough -- "Docbook -- The Definitive Guide" tells you how to do that
within the first few pages.  But if you want cross-references, or a common
index, well, the document processing system is going to have to chew through
each of the documents to find all of those references. 

What you might do is, for review and prototyping purposes, allow some danging
cross references (that is, build a "stub" document that includes only one part
of the big document), and keep the global overall framework for when you want
to create the "real" document w/ full index and cross references. 

BTW, I probably won't be requesting much help here in the future. My manager
has now forbidden all Docbook SGML use in our company, saying that it's "too
obscure" and "too difficult for managers to access" .  I've requested a pilot
study to see whether a common word processing program (StarOffice 5.2, a MS
Word look-alike) will actually do everything we've been doing with Docbook, but
I don't hold much hope that this pilot study will save Docbook -- the
advantages of structured editing aren't obvious enough for managers (who rarely
write large documents) to see. WIthout there being a brain dead word processing
look alike front-end on a cross-platform basis so that idiot managers can use
it on their Winblows lap-tops and Linux workstations alike, Docbook is
basically dead in our company.  

-- 
Eric Lee Green      There is No Conspiracy
eric@badtux.org     http://www.badtux.org  

  parent reply	other threads:[~2000-12-27  6:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-27  6:36 Peter Toft
2000-12-27  6:36 ` Norman Walsh
2000-12-27  6:36   ` Peter Toft
2000-12-27  6:36 ` Eric Lee Green [this message]
2000-12-27  6:36   ` Peter Toft

Reply instructions:

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

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

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=00071511261800.24882@ehome.inhouse \
    --to=elgreen@iname.com \
    --cc=docbook-tools-discuss@sourceware.cygnus.com \
    --cc=pto@sslug.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).