In order to see what is needed in book writing applications, you need Nature of the Task Approach
to look carefully at the desk of someone who is actively writing a
book. You will most likely see piles of paper, often cut up and marked
with pencil, and if you examine those of the papers that are in piles,
you will see that the pagination is all over the place because pages
have been reordered. Read on…
In order to see what is needed in book writing applications, you need
to look carefully at the desk of someone who is actively writing a
book. You will most likely see piles of paper, often cut up and marked
with pencil, and if you examine those of the papers that are in piles,
you will see that the pagination is all over the place because pages
have been reordered. Then, on the computer, you will probably encounter
a large number of independent files generated by a word processor
of some sort, mostly kept in folders according to the draft they are
from. You are looking at someone attempting to manage the passage
from one draft to another, and needing to change structure
as well as content as it is done. If you look more closely
at the electronic files, you will see a variety of formatting, fonts,
indentation etc, which has been set up manually as the document was
written. Ask the author how he/she likes this way of working, and
you will get a shrug. It is just the way its done. However, as you
start to think about this, you gradually realise that the traditional
word processor is in many ways not the right tool. If it were, all
this paper would probably not be needed.
You are likely to feel this even more strongly if you look at how
the formatting has been done. Most people cannot at the same time
manage to use the various layout features professionally, and compose.
So they often have recourse to what may strike you as fairly bizarre
ways of making the text look as they want it to. You will find for
instance, long sequences of spaces, or multiple tabs, or carriage
returns inserted to get pagination done. The manipulation of tables
will be especially problematic.
But what is better? Is there anything better?
The motivation behind this article was to find a better way specifically
for liberal arts authors. When one looks for software which would
do a better job than the traditional word processor, this means that
some packages which might have just the right combination of features,
if used correctly, are ruled out because of their user interface.
It is not reasonable to ask an historian or novelist, for instance,
to put in the amount of work it will take to learn Vi or Emacs, or
to expect them to learn the theory of regular expressions to do search
and replace. It is just not going to happen. I also have not considered
in any depth the packages which turned out to be unsuitable on an
initial screening. This left the following as more or less serious
candidates for the job:
The article tries to explain what the different advantages and disadvantages
of these are, and to make recommendations.
Nature of the Task
As an aside, to get the most out of any of these tools, your author
will need a good, large flat screen, 19 inch minimun, to free up physical
desktop space and to be able to use multiple windows, and a decent
keyboard. This is where any spare funds should be invested first.
It will also be worth spending some time with him/her on how to use
multiple desktops, especially if the screen is smaller. More technically
oriented people will be surprised to find that this takes a while
to get used to, but its worth making the effort.
Two or Three Tasks, Not One
There are three distinct tasks in writing a book: composition, document
structuring and page layout. The first two are closely related, though
maybe not in the way we usually think. The third is independent of
the process of composition.
Page layout is essentially typesetting – putting the words
and spaces down on a page for readability, and having regard to document
structure. Structuring a document is deciding and informing
the system, during composition mostly, which bits of content are,
for instance, margin notes, footnotes, titles, section headings. Composition
is the process during which one writes bits of a document, moves sections
around, inserts graphics, does search and replace – and in general,
gets thought onto paper, though not necessarily in final form at a
It is almost impossible to write a document of any length without
doing Structuring as a part of Composition. You and the application
you are using both have to know what bit of a document you are writing.
However, it is perfectly possible, and desirable, to compose, including
the necessary structuring, without doing any page layout at all as
you do it.
Lets try to make this clearer, because it is probably an unfamiliar
You can see the confusion between tasks that most packages lend themselves
to if you look at heading styles. When you pick ‘heading 1’ in a Word
Processor, you simultaneously pick some print style elements, like
Helvetica 16, bold, inset 5 spaces. This is Layout. At the
same time, you are telling the system that this is a top level section
heading. This is Structuring. It is logically possible to do
one without the other. It is quite possible to tell the system this
is a top level section heading, and have it display in Times 12 red,
but have it make an independent later decision to print in
Helvetica 16 black. You also often decide, in making a given element
a section heading, that what follows will be a moveable chunk. You
will mostly be able to drag this chunk around. But this too should
be independent of font, indentation and so on.
You can also see the confusion if you look at pagination and word
count and section numbering. Normally a WP program will tell you which
page you are on, and you may well use that as a guide to where you
are in the document. But which page you are on is a page layout/print
function. The number of words is the document authoring function.
The position in the logical structure of chapters and sections is
a document authoring function. The position in the content is what
matters for composition, not the position in the spaces that determine
page layout. In Lyx, which totally separates layout and composition,
you have no way of knowing pages until you go to PDF view or DVI view.
But you always can tell how many words you have written, and where
you are in the logical structure.
In fact, in Lyx, you use a carriage return to tell the system that
it has just ended a paragraph. In the display this puts in a line
feed, so you the author can see your para has ended. However, this
may result in a much larger or smaller space in the printed output,
depending on what class you are using, and multiple returns will not
put in any more space. The system already heard you!.
The effect is, that you never have to think about spacing when writing
a document in Lyx. But on the other hand, you do always have to tell
the system what parts of your document it is dealing with – chapters,
headings, sections, footnotes, bibliographies.
There are, then, two kinds of tasks in what we usually think of as
laying out the document. Task one is to tell the system how to classify
a given chunk of your document as being of a certain kind. This task
is inseparable from Composition, and we’ve been calling it ‘Structuring’.
You will usually write a document and think about content in logical
parts. That is, you will do Composition and Structuring at the same
time. Structuring will be part of the Composition process. Task two,
layout proper, is to determine a typesetting implementation to display
these parts appropriately on a printed page. This is something which
we need not and should not do while composing.
The classic example of confusing it all is when we use multiple carriage
returns to indicate to ourselves the start of a new section, and thereby
determine what the spacing will be when we print. Or when we pick
‘heading 2’ because we prefer the font to that of ‘heading 1’!
What Is Ideally Needed for Composition
If you look at the different tasks involved, and the ways in which
your author is handling composition with the aid of paper, and wonder
how to do it electronically, you come up with the following needs.
- An outliner, with the ability to place text into sections, and to
move these sections, including text, around in the document without
using select-cut-paste. The grandfather of outliners was the old More
package for Macintosh. In terms of manipulation, the two best outliners
I have seen for Linux are Leo and Treeline. There is some manipulative
outlining capability in Open Office and in KWord. Lyx is weak in this
at the moment.
- Navigation ability. Once you have written the document in sections,
you must be able to get to those sections quickly and easily via some
kind of navigator or table of contents. There are a couple of ways
to do this. Open Office does it by the Navigator. This is a menu pane
which can be kept on top of the document at all times, and double
clicking on it will take you immediately to the section of choice.
The Navigator pane can also be used in one mode as an outliner, giving
the ability to move sections around. Kate has a left hand pane which
does the same thing. Leo displays the document structure in a pane.
Lyx has a drop down, step through menu, which allows you to navigate
through the structure to the section you’re looking for. Of them all,
Lyx is probably the best, quickest, and least obstructive navigator.
You can either use it as a pulldown step through menu, or as a permanent
floating pane. But, Lyx does not have the ability to use it to move
- Search and replace. This should preferably not involve the use of
regular expressions! You need to be able to scan text by section for
strings, and manually pick what to replace. The author needs to be
able to manually pick, because regular expressions are too forbidding,
and consequently they will search for strings that are not only in
the words they want to change, but in lots of other words as well.
The kind of thing that works very well is in Open Office, both the
spreadsheet and word processing functions, and in Lyx, where it is
possible to find an occurrence and then make an individual decision
whether to replace.
- Support for document structure. You have to be able to indicate when
composing a book that parts of what you are writing fall into chapters
or sections within them, and that other parts are footnotes.
Support for bibliograhies is a desirable extra. Sometimes it is suggested
that to overcome the difficulties associated with traditional word
processors, authors should compose using a simple text editor such
as Gedit, Kate and so on. This is not realistic because of the lack
of support for structure. In eliminating all the layout features of
Word Processors, these packages also oblige you to keep the document
structure either in your head or on paper, or indicated by ad hoc
formatting in the text itself – for instance, using square brackets
for footnotes. I am sure novels and books have been written in Gedit,
but this is doing it the hard way. The best support for document structure
is in Lyx, followed by KWord and Open Office. Footnotes are not supported
at all in Kate, Treeline or Leo. It is a mistake to think these features
are page layout features. What fonts they appear in, how they are
displayed on the page – these are page layout features. The ability
to classify bits of your content as one thing or another is a composition
- Robustness. It must be possible to handle documents of several hundred
pages in length without worrying that a crash of the application is
going to lose material. This is apparently a serious problem with
MS Word Master documents. The problem is, that you want to have a
book of several hundred pages in one document, to use the outlining
features. But if this leads to instability and crashes, you are then
obliged to break up the book into distinct independent files, and
the only way to move material around becomes select-cut-paste from
file to file, which gets very unwieldy. Lyx is quite nice in this
respect, in that it it makes automatic backups as you write, which
are written to the work file when you save. OO is said to occasionally
crash, but be very robust in terms of file recovery. Kate and Leo
are essentially programming editors, and I have not come on any material
on their robustness in this application.
- Dual or paned views are very useful. This is a feature which allows
you to have two windows into the same document, but at different points,
and to make changes to either. The point is to be able to glance through
a long section of the book, at the same time as making detailed changes
here and there. The most sophisticated support for dual views is found
in Leo, which has the ability to put together different sections of
documents in different views, and to work on any section in any view.
Kate and Treeline also have quite nice dual paned views. Lyx and OO
do not support dual panes. To some extent this is made up for in Lyx
by the speed and convenience of the navigator.
What’s Needed for Layout
Your author is almost certainly going to have to submit paper copies
of his/her work, so they must be able to lay it out for printing in
a way that looks decent. It is not going to be possible to offer the
output of the typical text editor. This is where Lyx shines, as long
as you are happy to adopt the layouts that come with the program as
your own. If you want to customize them, you enter a world in which
the level of work is going to be quite out of proportion to the benefits
for the average user. OO and KWord on the other hand are WISYWG authoring
tools, and will permit a high degree of customization by point and
click, select and format. The results are not as professional as with
Export/Import formats. It is essential to be able to generate and
import documents in standard format that other people can use. Your
author may well be engaged in collaborative working, in which drafts
are submitted for comment, or sections written by other people are
received and must be incorporated into his/her work. One surprisingly
desirable feature in this connection, is the ability to lock documents
to ensure that unauthorised changes are not made. Industrial strength
locking is probably not needed, but the ability to generate PDF files
which can then be read by anyone, but not changed without deliberate
cracking efforts, is essential. Both Lyx, KWord and OO support this.
OO also will export in .doc or .rtf or simple text format. Lyx will
also export in ASCII, LaTex, or Postscript, but not .doc or .rtf.
Kate and Leo only support text. You must also be able to submit files
for publication in a form that the publisher will accept, which mostly
seems to mean .doc, but Postcript will be generally acceptable.
Lyx is a gui front end to LaTex. LaTex will be completely forbidding
to our target audience, but Lyx does an excellent job of concealing
LaTex complexity. To use it at a basic level is very simple. All you
do is start up a new document, set its type, or class, from the Layout>Document
menu, pick the formatting of your text from the Description menu,
and write. You can pick the usual kinds of formatting: numbered lists,
bulleted lists, bibliograhy format, section, sub section, sub sub
section. As you move through the document, you can write your headers
and subsections in advance in accordance with the outline plan, and
navigate through them with the navigator either as a floating window
or as a popup and step through series of menus to write the content.
When you are done writing, you view what you have written either as
DVI or PDF. The results are uniformly professional looking. Lyx seems
to have a reputation for difficulty, but if used like this it is not
merited. Footnotes and citations are inserted from the Insert menu.
Emphasis is done from the keyboard or from the Layout menu. Citations
and cross references are supported. Marginal notes can be inserted.
All in all, Lyx gives you the greatest power of any of the applications
considered to mark your document for publication in accordance with
how bits of it function.
One aspect of Lyx which needs careful explanation is the separation
between layout and structure. For example, in Lyx, if you hit the
spacebar twice or three times, only one space appears between words.
This is because the space bar simply tells the system it has reached
the end of a word. Spacing between words are set up later, in typesetting,
and happen automagically. Similarly, hitting enter ten times results
in a new paragraph with no more space between it and the previous
one, than if one had hit enter once. Spacing between paragraphs occurs
in another part of the wood.
There are drawbacks to Lyx.
Don’t try to change the predetermined format! For example, if you
have picked a list format, then each paragraph will be a new list
element. Now, you may want to have two paragraphs to one list element.
You can’t. Or not without getting deep into LaTex. Its not the end
of the world, you can figure workarounds, but it is a factor.
When exporting, while the export to ASCII is instant, and the result
is readable in any text editor, you get zero formatting. Lists will
end up preceded by asterixs. Footnotes will just appear in the body
of the text. Export to HTML and PDF is easy (you do need to install
latex2html, and then reconfigure Lyx).
When using the navigator, you can find sections very easily, but the
only way to move them around is select-cut-paste. It doesn’t support
drag and drop.
The insertion and manipulation of graphics is possible but not intuitive.
Tables are very easy to insert, but restricted in type. Don’t, for
instance, attempt to have a table with multiple line feeds in a cell.
Lyx seems rather robust in use. Force it to quit, for instance, by
killing the process, and the file you are working on will become unusable,
but an emergency file will be found in the same directory, and that
is usable. It also makes a backup as you go along, and if you forget
to save, will offer to use the more up to date copy on a reopen.
There are a great many programming oriented editors. At the extreme
of simplicity, you have Gedit or Kedit, and at the extreme of complexity,
Emacs or perhaps Vi. Leo is quite different from any of these. It
is a programming editor written around the concept of Literate Programming,
and has drawn a lot of its inspiration from More. It is the most powerful
outliner available for Linux, apart perhaps from Vim Outliner, and
unlike that, its outlining function is reasonably accessible to ordinary
users. You do have to be aware if recommending this that you are using
a programming editor for novel/book writing. So it is not going to
be either what the author intended, or a perfect fit. In particular,
a lot of the user’s guide is going to be irrelevant or confusing.
But despite this, it can still be the right tool for some people.
On starting Leo you see a three pane layout. The top right is a log
window, containing messages that will be incomprehensible to our target
users, the top left is a document structure window, and the bottom
is the text entry window. This will probably have to be rearranged
to show document structure on the left and text entry on the right,
and the log window eliminated. Text entries are highlighted and colored
in accordance with the requirements of Literate Programming; these
have to be reset for our purpose.
Once this is done, you end up with a classic outliner. You can have
nesting to any depth, which is expandable or collapsible at will,
and you move sections around by select and drag. This is quite powerful
and very easy to use, but there’s a lot more.
The greater power of the program becomes clear from the cloning function.
As the user’s guide puts it “Clones are useful for making alternate
views of a program. For example, when I begin to fix a bug I clone
all the sections of the code that relate to the bug, and place those
cloned sections under a new headline whose name is the name of the
bug I am fixing.”
Precisely the same thing may happen if one is writing a history, and
wants to look at all the sections touching on, lets say, famine in
18th century France, or certain families. The power of cloning is
that it lets you assemble all these parts in one place and go through
them quickly, without either having to page through the entire document
looking for them, or change the structure of the document.
All this comes at the price of some complexity. One will want to keep
the target user well away from large sections of the UG, particularly
those explaining tangling and untangling.
Leo supports document structure to the extent that the Outlining function
does. It doesn’t support footnotes, margin notes, Chapter headings.
You cannot paste graphics into it. The text it generates is fairly
accessible since the markup information is contained in the lead-in
to the document, and is not scattered through the text. It has zero
page layout functions.
KWord is a fine frame oriented word processor. Everything goes in
a frame. This gives it great power in applications such as newsletters,
where you may have a number of items each in its own area, and some
text has to flow around some items. It is great for cases where graphic
objects and text are interspersed. It does all the usual word processing
things in addition – footnotes, formatting. What it is not, is a good
outliner. In fact, if you compare it with Kate, what it adds, in terms
of document structure, apart from footnotes, is mainly the page layout
capability. It is very light on document management features, but
very high on page layout features. If you compare it with Leo, Leo
has none of its interesting features. If you compare it with Lyx,
Lyx does many of the same page layout functions, but the difference
is in customization. KWord is easily customisable by anyone, Lyx not
at all by most. KWord does support a document structure pane, which
is very similar to Kate’s, but this isn’t really an outliner. KWord
also exports and imports in rtf and doc formats.
The main issue with KWord, for our purposes, is that when a package
is totally frame oriented, you cannot get away from page layout while
composing. This is one of the disadvantages of traditional word processors,
and its a disadvantage which is accentuated by KWord. You can open
up a word processor and just start writing a long book. It would be
unwise to do this in KWord without clearly understanding the implications
of writing in a frame.
To do outlining and document structuring in OO, one opens the Navigator
and the Stylist in the Word Processing application. By double clicking
on a style, the line item on which the cursor sits in the body of
the text is given that style. The Navigator, if configured in the
right mode, will then show a heirarchical structure of headings, and
if placed into the right sub-mode will permit manipulation, ie moving
around of sections. There are the usual styles, footnotes are handled
well, and there are just about all the standard word processing features.
One can also set up a Master document, a function whose use has eluded
my ability to teach.
To use these features is to appreciate the ease of use of the Lyx
interface for doing the same thing. The default OO headings do not
structure the document in an intuitively heirarchical way. The Lyx
structure looks the part – as it should, since it is almost impossible
to change! OO does not. Headings two and three are not obviously subordinate
one to the other. As you do it in OO, you realise you are caught between
laying out the document as it will appear when printed, and laying
out the logical structure of the document. Users are tempted to use
headings as an indication of how they want the document to appear.
There is no reason not to. Thus, don’t like the way that heading two
looks? Just start the headings at heading three. Or heading four.
Why not? In Lyx, you will be forced to use the headings in their logical
sense, because at the composition stage, you basically are not controlling
at all how the document will look when printed. You are just classifying
its parts and getting the content down. In addition, the floating
panes occupy space on screen. You cannot deploy them in a separate
desktop because as soon as you use them, they merge all panes back
into one desktop. For some reason the drop down menu on the left only
shows you choices you have previously made from the Stylist. None
of this is fatal, but it makes an impression of great clunkiness,
and it gets in the way of, rather than assists, writing content in
a clear structure.
5. Treeline and Other Jots/Notes Packages
There are a great many of these, and in increasing order of functionality,
one can list: Kjots, Gjots, Tuxcards, TreePad for Linux, Treeline.
The first three are attractively simple, probably too simple for this
purpose, but I looked in detail at Treeline, which is an interesting
and powerful package, though with quite a steep learning curve. As
with Leo, if you go for this, you need to be aware that you’re recommending
your author use a tool only partially in accordance with its intended
When you start Treeline, the first thing you need to do is set up
your file for writing. The default mode comes with a one line deep
editor, and no fields defined except for the name field. If you want
to write documents, you’ll need to set up a heading field, a text
field, and make all of the extra nodes you create contain these fields.
It is not very intuitive, but it only has to be done once. The fields
can be of a number of types, including images.
Having done this, you now find yourself looking at a screen with a
tree structure of the document on the left, pages of the document
on the right, and three tabs at the bottom: Data Output, Data Editor,
Title List. The right pane is divided into two. If you create a document
with lots of sub headings, and then use the tabs, the power of the
application becomes apparent. You have two windows into the document.
The top scrolling pane, assuming you have selected a node which has
child nodes, will have the beginning text. The bottom scrolling pane
will have the subsections one after the other. The main difference
between the Output and the Editor mode is that in one you can read,
and in the other you can edit, and the Output gives more of the screen
over to the text. The Title list is only going to be useful in a document
of some complexity, but it gives a complete breakdown of the headings,
but in the main panes, not simply at the side.
You need a fairly big screen to make the most of this. But assuming
this is available, the ability to see both the main text and the section
text in two independent windows, and to resize the relative size of
each, makes for a powerful revision tool. For people used to traditional
word processors and scrolling linearly through a document, it takes
getting used to, but it is worth it.
There are some limitations to this. If you are looking at the whole
document tree, you will see the sucessive daughter nodes one level
in, in two scrolling windows. But you will not see the text which
is in subsections of these daughter nodes. To see that, you have to
go to the particular daughter nodes. This happens in both editing
and output modes, and is a disadvantage for this purpose. One really
wants the option to see the entire document in linear view, just not
for that to be the only view. But this is a common enough feature
of these kinds of packages. In kjots, for instance, you have the table
of contents of a particular document, followed by a scrolling list
of its contents, but there is no way to get the entire contents of
the tree as a scrolling list.
On balance, Treeline is a real contender. I guess the support requirements
would be higher than with Kate, and might amount to several tutorial
sessions, with practice in between. Your writer is going to have to
be motivated. Stability, as opposed to user interface features, is
a critical aspect of using such a package for a 500 page book. It
has not crashed and lost data, but I have not done stress testing.
Treeline has lots of features which are not relevant to our purpose,
and which make it an outstanding choice for a personal data & clippings
organiser. It is more complex than any of the other similar packages,
but far more highly featured. For example, the last revision supports
conditional fields. However, all that is outside the scope of this
If Lyx had two things, it would be the automatic choice.
One is rtf export and if possible import. The other is outlining manipulation,
the ability to move sections around and have the numbering automagically
adjust. Even without this, you don’t have to use it very long to understand
its popularity. The great advantage is that you can structure your
document properly, without having to worry about the aesthetics of
any particular implementation of that structure in typesetting. This
is an enormous time saver over any traditional word processing package.
Used like this, it should be fairly easy to learn – a lot easier than
most word processors. Used otherwise, ie with customized classes,
the learning curve will be vertical. It is very fast and very stable.
A second advantage is that the onscreen layout as you compose is attractive.
There is mininal toolbar clutter, and the various headings look right
and structure the document on screen in an easy and intelligible way.
It will be important to positively teach the use of Lyx, because although
basic use is easy, it is so different from what most people are used
to. But as long as you can remain with the predefined formats, it
can be taught in a few hours. It is well worth the effort to see if
you like it.
Leo is a superb outliner, and consequently much harder to
use than basic Lyx. It is worth considering for people who are highly
oriented to structuring their textual content, and who like to make
lots of notes, and work them into a constantly changing outline as
they go. Its also ideal for anyone who is writing a book which treats
the same subject from different perspectives in many different places,
because the clone function makes doing this much easier. For this
purpose it is probably unequalled. However, there is going to be a
fairly steep learning curve, and one should be ready for several days
effort to teach it, interspersed with practice. The difference is,
with Lyx you can leave after an afternoon and be fairly confident
that nothing terrible will happen. With Leo, it will take a lot more
work to get to that point. Leo is also unashamedly a programming editor.
This means that it doesn’t quite look the part aesthetically – not
to be underestimated. It may be more suitable for fiction writers
than others. I would suggest looking at Leo if you have someone who
is an instinctive outliner, is prepared to put the work in and will
value cloning, and who is mainly interested in generating a finished
document in text, and handing on the layout task to someone else.
Kate has about the same learning curve as a basic use of
Lyx, but is much weaker in document structure features. There is no
support for footnotes, chapters, sections. Not a problem if your author
is a novelist, but a killer for many uses. For a novelist, the dual
editing view into a document could be a great asset. Unlike Leo however,
you don’t get the ability to use this dual view as a collection of
items on the same subject. Files generated with both Leo and Kate
will have to be exported, and then imported into some other package,
like OO or Lyx, for layout. Kate is worth considering seriously for
fiction writers, and will be much better than stripped down editors
like Gedit, which I have heard suggested to refugees from WP. It has
a nice, clean, attractive, user interface.
If you recommend either Kate or Leo, be prepared to teach how to export
the document into some other package for layout. If documents are
going to be received in .doc format, you will also have to show how
to import them into OO, and how to then get them out of OO and into
Kate or Leo. This is probably not very sensible if its going to happen
OO has many of the document structure features found in Lyx,
with all the traditional word processing features as well. It is notoriously
large, slow to load, but is reported to be stable and not to lose
material. The navigator and stylist work best as permanent floating
windows, and for this a large screen is needed. If your author hasn’t
at least a 19 inch screen, get them one, and they’ll find it worthwhile
for this use alone. Outline mode is a bit clunky, but it does allow
movement of sections of text around. It is very easy to insert graphics
– and of course, sections, sub sections, footnotes etc are well supported.
It has a fairly steep learning curve in itself, but for someone who
is familiar with modern word processors, as most are now, this will
be much reduced. If navigator and styles are used, its a good choice.
The choice between this and Lyx are down to personal preference. Lyx
will produce more professional layout with less effort, and will be
faster and easier in composition – owing to the lack of any layout
during composition. OO will be more familiar to people who are used
to Office packages. If someone is going to be doing a lot of exchange
of documents with people using MS Word, then OO is the only way to
go. It should then be set up to save in .doc or .rtf format as a default.
KWord is a true frame oriented page layout package. It does
classically what Lyx tries to avoid – it makes you lay out your pages
in the course of composition. Not recommended for this purpose, though
as a simple and powerful page layout program, it looks excellent.
Treeline is an interesting, complex and powerful program,
arguably the best, or at least, most highly featured, of its kind,
whose main use is for other purposes than book writing. These packages
in general have a lot in common with outliners, but their lack of
document structure features probably rules them out for recommendation
for serious book writing for most people.
The Last Word
Well, this was written in Lyx and exported as ASCII. If you support
an author, learn it yourself, and then teach them and have them try
it. They and you may be surprised how easy life becomes when page
layout is totally separated from the logical structuring of documents,
and from the composition of content.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.