Possible to do Master Docs Inside Master Docs?

[KirkWard]

I have a large document with maybe fifteen or twenty chapters. Each of these chapters has maybe a dozen or so sections with smaller topics in each one.

I would like to set up my chapters as master documents and have the dozen or so sections in each one as a subdocument, and then pull all of the completed chapters into one master document.

I cannot find anything that indicates having multiple layers of master documents is possible. If there is, could someone either explain it to me, or point me to a tutorial? Or, if its not, then maybe give me some ideas for a workaround?

Many thanks,
KW

[ajlittoz]

Master/subdoc feature has two main application cases:

• Improve performance and stability of Writer with “large” documents

  “Large” depends on your computer configuration. On antique 500 MHz Pentium 3 machines with less than 1 GB of memory, “large” begins at around 250 pages. With current machines, documùents with 500 pages are managed like a treat. They need to be much bigger to have a noticeable effect (depends also on complexity of contents).

  This does not seem to be your case.

• Share parts between various final documents

  An example would be a library of legal clauses to be assembled into a contract. You repeatedly reuse different clauses for different customers resulting in ad-hoc contracts with only the relevant clauses.

  This does not seem either to be your case unless you edit your question to give more details.

[Hrbrgr]

No, I’ve never heard of it.

There is only one master document with several sub-documents.

[ajlittoz]

I confirm this. Writer refuses to insert any .odm in a master. Only .odt are accepted.

[KirkWard]

The “Clunky” workaround I have been considering is to make each chapter a master, with its own subdocs, and then when I was satisfied with the result, either export each chapter into an .odt and use them as subdocs for the “Master of Masters” or just pull all the subdocs into one huge master.

The term large was used based on the quantity of units and topics. I know it is a rrelative term, but I used it because of the relative complexity of the topics. It is an operations manual for a complex business entity and with all the different units that will be going into it, I felt each one needed to be able to be created on its own.

[ajlittoz]

Another approach would be to go along with your “chapters” as masters issued as independent books (unless you have cross references between the chapters, but I doubt it because of your structure).

Then you have a “catalog” as an “index book” listing all the chapter-books with their revision number, reference or other quality assurance-important items. When something changes, you update the chapter and the “index” and only reissue modified books. This happens to be less exprensive than reprinting the full collection.

[KirkWard]

I think this may be the best thought. It feels like a smoother version of my clunky method, and one that would work. Now I have to learn how to build an index in the master-master. Would you suggest just doing it manually, or is there a way to capture the build date of the sub-masters?

[ajlittoz]

Fifteen to twenty titles does seem to be manageable manually. But if you insist on automating the process (which would prevent manual editing errors), you can write a small script (shell, perl or whatever you like and feel comfortable with) to capture the content of some directory where you archive your work, something in the like of ls -l in Linux. You filter the output according to your criteria and you build a text file with file name and date of last modification. You may also use a “dictionary” file giving the correspondence between book title and filename (this could also help diagnosing missing files or extra files) to add the title in the text file.

This text file is then the basis for a “mail merge” step for your index book.

Possibilities are nearly infinite.

An advice of a former quality vice-president in a big firm: make things simple, they’ll be more reliable.

[KirkWard]

Thanks Ajlittoz, I understand your concept, and actually like it a lot. Big drawback is that I as a 78 y.o. non-coder have no longer have any idea how to code the new stuff. Only modern language I knew recently was web php. Before that it was COBOL, and I have forgotten that (thank goodness).

I do promise to cogitate on the concept and see if I can lay out a flowchart on paper and then find someone to help me put a script together. It will be a learning experience, but what the heck, at 78, I have the time. LOL

[ajlittoz]

@KirkWard; ah! COBOL, sweet memory of my youth time! It was probably the best way to handle data tapes in that period of proprietary encodings, formats, etc. Transcoding was relatively easy and after you could submit the data from the tape to FORTRAN or PL/1 compilers, not ot speak COBOL.

[KirkWard]

Ha @ajlittoz, I had forgotten my Fortran years. Learned said lingo whilst in ye olde college days.