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.
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
first draft.
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
concept.
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
sections around.
- 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
feature.
- 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
Lyx.
Other Considerations
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.
The Applications
1. Lyx
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.
2. Leo
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.
3. KWord
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.
4. OpenOffice
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
purpose.
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
note.
Conclusions
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
often.
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.
I didn’t read it in depth yet, but from what I read so far, this is really a very nice, informative and informed article.
Thanks a lot.
LYX is not the same as LaTeX. why did you not include it?
Probably because “The motivation behind this article was to find a better way specifically for liberal arts authors”.
I can easitly see a liberal arts author spending the four or five hours it’d take him to learn what he needs to know about Lyx to get the job done.
On the other hand, while I dearly love LaTeX, I’d much rather see an author concentrate on writing content, rather than spending the weeks it’d take to learn what he’d need to know about LaTeX.
On the other hand, while I dearly love LaTeX, I’d much rather see an author concentrate on writing content, rather than spending the weeks it’d take to learn what he’d need to know about LaTeX.
Well, it took me one afternoon to get the first 30 pages of my thesis from OpenOffice to TeX. Main reason to do that was that I was wasting too much time fighting the way OpenOffice dealt with embedded images. TeX produced an excellent layout without me even worrying about layout at all, instead focussing on the content.
LaTeX is not at all prepared for book writers, in fact it is not prepared to be used by any content-creator unless he/she needs to:
a) create a content in an already set framework (eg. using dedicated style for a publisher accepting LaTeX entries)
b) create very complicated maths / music score (I mean he REALLY knows what he is going to achieve).
TeX/Latex is _typesetting_ machine, so it _typesets_ a content, nothing more. It’s up to an author to provide the structure of content, and there are no aids/handicaps.
In fact if one uses basic classes, he just gets nice output. But if you want to get REAL BOOK (I mean good typesetting on bookstore level) you must break with creating content and work with low level non-structural typesetting commands/macros. This work is to be done on editor’s side — in fact it is my job, I earn by typesseting books with LaTeX, not creating them
, absolutely not on writer’s/author’s side.
> I’d much
> rather see an author concentrate on writing content,
> rather than spending the weeks it’d take to learn what
> he’d need to know about LaTeX.
I agree it takes much time to learn LaTeX, but it pays off in time. Even short 20 page articles are hard to maintain with wordprocessors like Word if the output must be professional quality (consistent style and references), but with LaTeX it ends up to be fast and easy to change style and have professional quality with both styles.
Whatever the tool, doing layout manually is waste of effort in the long term. Earlier this year we composed a book of 450 pages from 40 different authors. Almost everyone submitted us their work in LaTeX ( http://samos.et.tudelft.nl/samos_v/ ), and it was enjoyable to edit those documents because we could get professional look almost automatically. Some authors submitted their document with wrong style, but with LaTeX it was possible to correct that by editing just a few lines on each document 🙂
These days I like Lyx and LaTeX because they save manual layout work. Anyway, I’ve been thinking to write my documents in Wiki too 🙂 With a good browser and nice fonts it’s almost enjoyable to write articles.
Regards,
Heikki Orsila
“On the other hand, while I dearly love LaTeX, I’d much rather see an author concentrate on writing content, rather than spending the weeks it’d take to learn what he’d need to know about LaTeX.”
Weeks? Why would it take weeks? What on earth would they be trying to learn that would take more than ten minutes? It would still be a sadly impractical choice but not for learning curve reasons. Perhaps someone may write a literary extension like the musical musitex.
Actually I’m a liberal arts writer and I use Latex. Admitedly I started with LyX on Linux, but changed to LaTeX, with TexShop as the editor,when I switched to OS X.
The most likely reason the writer did not include LaTeX, is that LaTeX is a mark-up language, not an editor. The usefulness of LaTeX to an author will be affected by the editor they use and it is therefore more appropriate to review available editors.
TexShop is good, but not available on Linux. There is a Qt based editor I tried on OS X, which is also good and I presume available for Linux (can’t remember write now). It had good structure layout and included tabs, which is handy for editing multiple chapters at a time (each chapter a different document).
“There is a Qt based editor I tried on OS X, which is also good and I presume available for Linux ”
Can you remember what it was? Not texmacs presumably, which supports clone views but not I think tabbed views. The tabbed view aspect sounds very interesting. I have looked but haven’t come on any obvious candidates
A tool that is often overlooked for anything other than programming…
A good version control tool like Subversion would be of great benefit as well. I’ve come to use Subversion for everything important from source code, letters, my resume rather recently, to MP3 files.
This makes backups easy, change tracking even easier, and gives me a nice time based snapshots! On top of all of that it also allows me to work any any one of my multiple computers (my desktop, my laptop, or even a friend’s computer with svn+ssh) without fear of losing anything!
Of course that really biases the tool selection toward a text based approach like \LaTeX{} because then you also get the HUGE benefit of being able to see the differences between the versions easily!
Edited 2005-12-20 19:44
Yes yes yes. I cannot live without Subversion. I can prepare my materials on 6 different desktops in two different, remote places + ssh on server. Everytime up to date, everytime knowing there are at least 2-3 nearly complete safety copies on different disks in different computers in different buildings.
It’s a well written article. But the author does ignore the fact that your choice will most likely ultimately be determined by the publisher you are working with rather than any personal preference you have.
As someone who has written published books, doing the writing on both Linux and FreeBSD, I have to say that most of the time, if you are working with a publisher, the only real option will be OpenOffice.
Why? Because your publisher will almost certainly use MS Word. And most likely, they will use some of the advanced features of MS Word–particularily revision tracking / document collaboration to make it easier for you to communicate with your editors (yes, usually there will be more than one) and accept / reject suggested changes and so on.
OpenOffice is the only one of the mentioned options that has good support for MS Word’s revision tracking and document collaboration features. In fact, it worked flawlessly and I was able to work freely with my editors who were using MS Word.
Lyx is nice. But only the most technical publishers will accept LaTeX documents, or even Postscript. The vast majority will require a commonly supported word processor format. And many will only work with MS Word because of document collaboration and such.
Edited 2005-12-20 19:47
I thought about writing an article on this subject, but after some reflection I realized that it would be useless to anyone but me. I’ve written three books and contributed to and edited others, including a top-selling Linux book. I’ve never used anything other than high-end word processors for all of my work. Word 97 when it was the best and brightest, then WordPerfect 10 and 12, and now TextMaker and StarOffice. I need to see typos and spelling errors as they happen because I write organically, sort of in waves of drafting, revising, and editing. Other writers need outlines first, then chapter synopses and such.
Every writer is different, and will use different tools according to preference and need. There is no end to the evangelists pushing Emacs and Vim and (especially) LaTeX. You can’t use these effectively as a professional writer because publishes almost exclusively work with Word .DOC files, although some will take WordPerfect .WPD as well. So yeah, you could write in Emacs, save as a text file, and then go through all 300+ pages again in OpenOffice or Word or whatever to put all of the formatting back in for the finished manuscript. But you’d be silly to do that without a very good reason.
There is a program called NewNovelist which helps facilitate outlining and other writing preparation. It’s pretty cool, but as I said, I don’t really write like that.
Personally I would love to have a word processor that allowed me to do a sort of storyboard or timeline across the top or bottom of the screen while the text window is open. A spelling and grammar checker (please don’t make me explain why grammar checkers are important. The short answer is: they catch correctly spelled typos) that checks in real time (not after the fact in a popup window — I hate that!), and excellent font rendering. I have actually considered writing such a program by isolating and specializing the word processor in OpenOffice.org.
“There is a program called NewNovelist which helps facilitate outlining and other writing preparation. It’s pretty cool, but as I said, I don’t really write like that. ”
I see lyx not by itself, but fitting into a larger workflow. Imagine NewNovelist at the top of the pyramid, and latex near the bottom. This works even better when you have writers collaborating.
Certainly some authors do more than others, but isn’t it hard enough to find someone expert enough in the field enough to create content to also expect them to be typographers and layout specialists, on top of the production details of getting a book printed? I would think that kind of effort would be sourced at the publisher.
Certainly the days of shipping off a stack of handwritten legal pads off to the publisher may be mostly long gone (though many writers do still write this way, they just happen to have their own typist key it in to something more managable), and while I’m sure authors may want some input in to the overall look of the book, many of the modern technical books have there L&F dictated by the publisher from the get go it seems to me. Many journals also dictate format, and magazines simply have the most strange layout constraints that the author probably is completely hands off.
So, while structuring the work seems important, fixating on the typography is stretching it a bit I would think.
I’m a tech writer/hardware reviewer, and I’ve found that Ulysses is probably the best tool that I’ve found for the job so far. It’s basically a word processor, but with a twist — it’s oriented towards the out-of-order work that creative writing is.
I would urge anyone who likes to do some writing now and then, but finds the typical office-oriented word processor to be a piece of cumbersome crap, to take a look: http://www.blue-tec.com/ulysses/
And no, I don’t work for them. I just like their application. Oh, you’ll need to be running a real OS too, since this is an OS X-only app. 😉
Wow!
That Ulysses application is pretty neat. Didn’t take me so long to figure out the interface either. I particularly like the full screen mode. Thanks for the tip!
Yeah, the full-screen mode is awesome — no interruptions, just simple, sexy yellow text on a black screen.
No problem, by the way.
just simple, sexy yellow text
Do you have the yellow text fetish?
Oh yes.
I also have a whole collection of stuffed Tux penguins … they touch me at night.
I have to agree that LyX is GREAT for some uses… for instance its the perfect too to write a school paper, masters thesis, PhD papers, and even academic and medical journal articles etc.
But not sure if its the right tool to write a book for random-house.
I have to write a lot of papers, and this article was really helpful.
Until now my primary tools is MS Word 2003. It can do everything: structuring, spell and grammar check, easy viewing, layout control, and so on. I like the option in Word and OO to add temporary comments and markers that do not show up in the printout. If it only exported to readable HTML…
The whole article provides a good overview, but gives the reader the impression that one should not get to see LaTeX Sourcecode for writing a book.
I consider Lyx a good approach, but it has disadvanteges when it comes to finetuning of the output. On the other hand learning of LaTeX is not that difficult for somebody who is willing to read documentation and work with text based editors.
LaTeX does provide all the functionalty for professionel/scientific books. However, when it comes to mainly layout based documents LaTeX is the completetly wrong application and DTP programms are needed – but that applies to all the programms in the list of this article.
Therefore I really miss Kile (KDE Integrated LaTeX Environment) in the list of editors for Linux. One could of course add emacs and other editors with LaTeX enchancment to this list as well.
The main problem of acceptance is that LaTeX is not standardised. If have heard of one article which only accepts basic MS Word documents and converts them to LaTeX before printing.
Matthias
This is a great article; hopefully there will be a lot of these on OSNews. I’m about to start with my Master’s Thesis so I’d love to hear what everyone else is using.
As to the fact that most Publishers use MS Word…hmm I bet if one day that woman who wrote those harry potter books decides to write with LaTex and would only let publishers that read LaTex publish her book, maybe every publisher would switch:)
This is one of the better articles I’ve seen in a while and pretty informative too. I didn’t see much bias in it at all. I was expecting a jab at Microsoft on every page due to the linux keyword in the title, but there was only one mention of them and even that wasn’t a jab but pretty much the truth. MS Word is good, but handling several hundred page document it just doesn’t do well at it.
More articles like this are needed. Keep up this kind of good work, because you have convinced me to try some other writing applications on linux.
> MS Word is good, but handling several hundred page
> document it just doesn’t do well at it.
True, but typically one doesn’t write entire books in a single file. They are usually one file per chapter to facilitate easier editing, and allow editors and authors to work at the same time (editors can be editing existing chapters which will then be sent back to the author for revision while the author is cranking out new chapters at the same time).
It’s only after the book is entirely written that a single file of it is produced by batch processing all of the chapter files. And that file will usually be a PDF proof. Not a Word document.
Edited 2005-12-20 22:32
A screenshot of Word 2003 with document structure and styles & formatting:
http://www.evert.net/temp/word2003.png
I wish that everybody would use styles correctly no matter which program that choose to use… I’m always the evangelist when it comes to that as I can’t hardly stand to edit a document produced by anybody who doesn’t use them.
That said, MS Word 2003 has a horrible memory leak or other bug where when you’re using styles it becomes VERY slow, stops responding, and stops updating (or even updates incorrectly) when using styles in a large document. I have to close the program every 1/2 hour at the least if I’m using styles. Sad. Makes it hard to convert people. I prefer OO.org myself. I believe that OO does a better job of separating style & content than MS Word. I also prefer to have to double click (as in OO) to apply a style (ooops!). I also dislike how Word automatically creates styles form other people’s manual changes and then they sometimes won’t go away when you apply a style correctly.
Very true. Sometimes Word 2003 even “forgets” the structure in the document, and I have to restart Word to fix it.
The intended audience is not defined and application categories are mixed.
It isn’t clear why lyx qualifies but vim+latexsuite or emacs+auctex doesn’t. A occasional document writer would never even look at these applications and a professional writer should be willing to learn the right tool for the job. Dismissing two popular editors because of there learning curve would be logical for once-in-a-lifetime witers, but why should daily users dismiss it?
A programming editor, a DTP app, an office suite, and lyx should be comparable because…? You might as well include Scribus, which is a kick-ass DTP program.
Disclaimer: I am biased towards vim, latexsuite, darcs (revision control), and scribus.
“It isn’t clear why lyx qualifies but vim+latexsuite or emacs+auctex doesn’t.”
Technically yes, far more powerful. But can you teach it in a reasonable period to the particular people? And can you feel safe leaving them to use it with phone support?
Don’t think so. Its not stupidity. You can be dealing with the world’s leading expert on the evolution of the English Common Law in the Middle Ages. Its just minds that work in a different way, and the important thing is, giving them stuff that they can and will use, and be relatively independent of you once they are using it. They will accept Lyx. I don’t think there’s any chance of teaching them Vim.
Similarly Kile. Really want to keep them away from Latex source.
Scribus: isn’t the problem that it is true page layout? Whereas what we want is to separate the logical structuring of the docoment from page layout? I don’t know Scribus however, so this may be wrong.
Texmacs, as someone suggested, yes, a real alternative. Maybe not quite as familiar in look and feel as Lyx.
The problem with an Emacs/LaTeX setup is actually mostly getting it set up well, with working LaTeX, AUCTeX, RefTeX. Once it is well-configured, most people get along reasonably with it, even from a non-technical background. Hand them some printed intro into LaTeX. Sure, you’ll be surprised at some of the mistakes they’ll make, but you’ll also be surprised at their ability to dig themselves out of holes again.
I’d much sooner do phone support for such a setup than for any word processor: the good thing about this is that all the information is on-screen. “I did nothing different” is the _standard_ phone support cry, and since you always have the source file on-screen, there is always a way to pinpoint what happened. You can give sensible advice seeing screenshots, you can get sent sensible extracts, and so on.
And you don’t need to worry about what buttons to press: when in doubt, you can always just type in LaTeX commands letter by letter. This is faster than trying to navigate by phone through half a dozen menus.
Emacs does not have much of a learning curve before you can use it nowadays. You’ll never get to the state where you think you know it inside out, but that does not keep it from being workable.
texmacs
I’m another person who uses Kile to write my papers with, and the LaTeX that you need to know is learnable in less than an hour, IMHO.
I’m no geek, I use PCs to get my work done, and LaTeX is great for letting you concentrate on the structure and content of the paper rather than be distracted by the layout. LaTeX served me well while I was doing the dissertation for my law degree, and I’m using it for all the assignments and the dissertation for my MBA.
Oh, and with all the talk of LaTeX, typically is overkill unless you are writing something mathematical or scientific where you need to write up lots of formulas and such.
troff is a lot simpler, and is really quite a capable markup languages. O’Reilly still accepts troff as far as I know, and I also know authors who have written books for O’Reilly using troff.
troff’s markup language is also quite a bit simpler to learn than LaTeX.
LaTeX is awesome for research papers. The ability to manage the support materials that go into a paper are astounding.
When I was a phd student in 96, it was very easy to notice when a paper has been written using LateX: either all the images ended up at the end of the section, or (in the good case) the images were only put the page after the reference.
This was very annoying because to read the doc you had to do a lot of back and forth, ugh!
Either Latex has improved a lot or we do not have the same view on what is ‘professional output’..
That probably means that the people who wrote those articles either didn’t know LaTeX very well or that they chose to have their figures in the end of the document. Though I think the default LaTeX handling of the figure/table placement could be much better, it’s actually very easy to “tweak”.
For each figure, you have a placement option which tells LaTeX where it should be placed. For instance “h” means “here”, “!h” means “here, pretty please”, and “H” means “here, damnit!”. You can also set your preference for placing the figures on the top (“t”) or bottom (“b”) of a page, or indeed on a separate page in the end (“p”).
I don’t know what typesetting/word processing software you use, but I generally recognize articles written in MS Word by their poor typesetting, especially when it comes to equations. Even with MathType, equations in Word don’t look very good, IMO. Also, my personal experiences with long reports in Word haven’t exactly been very good; in one instance I ended up with all the figures in the end of the document, after about 30 blank pages.
That probably means that the people who wrote those articles either didn’t know LaTeX very well or that they chose to have their figures in the end of the document.
That’s a very cool way to say that these people where completely ignorant and stupid. The first thing you learn in working with images in LaTeX is how to place them, as it’s included as an option in the command that allow that.
I don’t know what typesetting/word processing software you use, but I generally recognize articles written in MS Word by their poor typesetting, especially when it comes to equations.
Don’t have to go as far as equations. For any document, just look at text layout. You will see that it looks like crap on every Word document, because, depending on your alignment style, every line has some big spaces or ends of lines are too short or too long.
That’s one of the reason LaTeX looks immediately more professionnal, it uses things like hyphenation. A good hint to recognise a LaTeX document is that you will find hyphens, but not in a Word document.
That’s a very cool way to say that these people where completely ignorant and stupid.
No, not at all. In fact, I sincerely doubt that any of them are ignorant or stupid. I still can’t see any other way to explain the OP’s gripe with LaTeX than I did, however.
It might be that they indeed favored having the figures in the back of the document. I personally don’t like that, but some probably do. After all, the LaTeX figures do have an option for doing exactly that.
If that wasn’t the case, why you you think that lack of proficiency with a software tool equate ignorance or stupidity? Maybe they had a lot of large figures, and weren’t aware of the float package? In such a case, the figures will get pushed off to the end. (As I found to my dismay until I discovered the float package.)
Anyway, you shouldn’t be so quick to jump to conclusions about the intent of what people write.
Renox wrote:
> either all the images ended up at the end of the section,
> or (in the good case) the images were only put the page after the reference.
I don’t know how much LaTeX has improved since then, but using current versions that would mean authors had instructed LaTeX to put figures into wrong places. The best default policy is not to instruct where the pictures are put.
Regards,
Heikki Orsila
I love articles like this that lead me to try new things, in this case Lyx. And it’s a very informative article too. Thank you, Mr Author.
However, I’ve been over many hundreds of manuscripts over the years as a job of work and 99/100 are in a standard-issue word processor, usually MS Word. With a few exceptions, authors are not technical types. They want something that “Just Works” and that they feel safe with, and publishers want a predictable format to deal with, probably specifying “MS Word compatible” in the original publishing contract or in a house style guide. In my experience, the exceptions are highly technical works for which a standard WP won’t do or where the author is contracted to provide some of the design as well, perhaps templated around a page-make-up proggie. Very, very occasionally, delivery has been taken off old manual typewriters or even hand-written scraps, but only if the book is saleable enough to justify the expense of having it cleaned-typed on a PC.
An author’s manuscript needs to be very easy to read (or speed-read), edit and annotate. That means minimal formatting in double-spacing and fairly large type. The design stuff all comes later. One reason is that the size, look and length of a book are also a function of its niche in the market, and that needs to be got very clear before any design work takes place. It’s no good offering a book of 450 pages at 9.99 in a market that really wants 320 pages at 6.99, or vice versa.
I have been involved in making the layout of some scientific books (in the field of Plant Physiology). First of all, it is simply false that most publishers prefer Word documents. Many publishers prefer camera-ready copies or PDF files. This gives authors and editors pretty much freedom. The books that I helped with were written with Word, because that is how manuscripts usually come in fields outside Mathematics or Computer Science. In *my* experience WYSIWYG word processors are really bad for formatting books. It is hard to get the layout consistent and tidy. Besides that the WYSIWYG interrupts writing and editing, since it is pretty distractive.
Naturally LaTeX and are good choice, or for computer-related manuals DocBook plus JadeTeX (which can be a pain at times, to get the printed output straight). It is funny that troff is not mentioned here. While it may seem a bit archaic to some, it is a nice typesetting language, which allows for a lot of customization. Both at the troff level, and at Postscript level. Besides that troff files can be easily changed with the standard UNIX text utilities.
Troff is quite easy when used with the mm or mom macros:
http://faustus.dyn.ca/mom/mom.html
Troff was used, and continues to be used for many good UNIX related books. The excellent troff.org site provides a list of books typesetted with troff/groff:
http://www.troff.org/pubs.html
(Yes, I know that troff is not usable for everyone, but it is a good tool for more tech-savvy writers.)
“First of all, it is simply false that most publishers prefer Word documents. Many publishers prefer camera-ready copies or PDF files. This gives authors and editors pretty much freedom.”
That hasn’t been my experience at all. Because typically PDF files are not editable. And I have actuallyy never worked with a publisher who wanted camera ready copies. In fact, most of them specifically say they *do not* want camera ready files. They have their own layouts that are common for their imprint ect, and they have people whos job it is to make sure your manuscript conforms to that layout. So typically they will give you Word templates with tags. The Word documents end up looking nothing at all like the actual product would look.
The publishers I have dealt with have been in the IT field, and the entire process has been completely paperless until publication. All the writing and editing was done in Word. The final proof was a PDF (that was camera ready) where I had to note incorrectly placed figures and all that. But nothing left Word format until the final proof which was PDF.
“In *my* experience WYSIWYG word processors are really bad for formatting books. It is hard to get the layout consistent and tidy. Besides that the WYSIWYG interrupts writing and editing, since it is pretty distractive.”
No publisher I have ever worked with wants you to do your own formatting. They have templates with special tags they want you to use for various level headings, figures, etc. The Word document is not at all WYSIWYG and looks nothing at all like what the final product will look like.
Edited 2005-12-21 04:25
That hasn’t been my experience at all. Because typically PDF files are not editable. And I have actuallyy never worked with a publisher who wanted camera ready copies. In fact, most of them specifically say they *do not* want camera ready files. They have their own layouts that are common for their imprint ect, and they have people whos job it is to make sure your manuscript conforms to that layout.
Interesting! Maybe this differs per country or field of science. Maybe the books you submitted were part of a series with a uniform layout? At any rate, the change that we have noticed is that publishers have started to offload more and more over time. Editing and making the layout is not done by them anymore, they basically print it, and that’s all. For them, it gives a wider margin. And no, these are not cheap publishers, but established and well-known academic publishers.
Then again. Most good UNIX books were typesetted by the authors, and submited as a camera-ready copy.
No publisher I have ever worked with wants you to do your own formatting. They have templates with special tags they want you to use for various level headings, figures, etc. The Word document is not at all WYSIWYG and looks nothing at all like what the final product will look like.
I have no experience with such templates.
“Maybe the books you submitted were part of a series with a uniform layout?”
Well, most common publishers (at least in IT) have specific formats for specific series. O’Reilly for example has a certain way they want headings to look for their animal books, and certain formatting conventions for tips, warnings, code listings, new terms, commands to be typed, etc. They also, of course, have certain icons that they use for tips, warnings, and so on. Their Developers Notebook series, and their Head First series, of course, have other stylistic conventions. If you saw a few inside pages from an O’Reilly book, and you didn;t know what series it was from, chances are you could guess just from the stylistic conventions without even knowing the title.
Part of what makes a Head Start book, a Head Start book, or an animal book an animal book, are those formatting, layout, and style conventions. So they generally don’t want authors giving them camera ready art, or WYSIWYG documents.
Some of the layout and formatting would probably be almost impossible for authors to do unless they were desktop publishing experts. For example, people with thought bubbles coming out of their heads are common in the Head Start series. That kind of thing is not easily done in any of the tools mentioned. (And even for authors that do decide to do it on their own, it usually requires a fair amount of experience and skill to make this kind of thing look right, so the publishers will typically have their own design staff redraw them anyway).
Typically, in my expierence, writing IT books has been more like writing HTML the way we used to do it. We just use tags to say what we want, even in Word, without worrying about what it actually looks like. Example, [H1] for a level 1 heading [H2] for level two [Li] for list item, and so on. The Word templates often have macros that the publisher can then run to look for these tags and remove them, while converting the following text to the desired style and such.
I really hope that OOo v2 improves on the bibliographic component, because it could be a killer app against Word+Endnote. I am studying Litt at the MA level and so I must use MLA style formatting. When I did my BA I wrote a lot of papers in LaTeX, but frankly, the current MLA style for latex is just sub-par for a more complex document like an MA thesis. I have to stick with Endnote/Word right now because it’s the only package that will give me a proper, up-to-date formatting of my bib, and which will allow me to follow my university’s style guidelines without painful hacking.
People always bitch that WYSIWG is bad because you are formatting as you write, but goddamnit! you can’t get a good sense of where your writing’s at if you don’t have a decent visual feedback. This is no different than working on a typewriter: you did formatting and content at the same time. Using latex is no different: you still put the italics and bold while you type. But instead of seeing old{blahblah}, I’d rather see it properly formatted onscreen. Footnotes in latex are in the middle of the text, so you need to read
text text text text text text text text footnote{text text text }text text text
Whereas having
text text text text text text (1) text text text text text
(1) text text text text
Is much more practical and easy to apprehend.
I wish for a real model/view writing system, a bit like LyX, where you can see approximate formatting, but keep a strong structure that you can abstract from the view. However, LyX has an ugly UI, and I’m not going to limit myself to MLA latex bib style.
Current versions of AUCTeX, the prevalent LaTeX mode for Emacs, can fold footnotes using either a source-based folding approach or by using preview-latex (which typesets the footnote marker as an image and places that in the source text).
In addition, footnote and other macros get auto-wrapped on entry or reformatting in a manner setting them off nicely when reading the source.
People always bitch that WYSIWG is bad because you are formatting as you write, but goddamnit! you can’t get a good sense of where your writing’s at if you don’t have a decent visual feedback.
BS. The “decent visual feedback” is the text, not the formatting
This is no different than working on a typewriter: you did formatting and content at the same time
No you were forced to. If a program can do it for you, and correctly as a matter of fact, it’s way better.
Sorry to tell you that you could not easily edit your text on your typewriter.
Using latex is no different: you still put the italics and bold while you type
No you don’t, so it’s different. You do that when it pleases you, which may be as you type or not.
But instead of seeing bold{blahblah}, I’d rather see it properly formatted onscreen
Use a proper LaTeX editor then. There are some good ones even on Windows.
Footnotes in latex are in the middle of the text, so you need to read
No they’re not. You put them that way, because you are stupid.
I put mine like this :
text text text text text text text text footnote{text text text}
text text text
This seems like being rocket science to you …
Whereas having
text text text text text text (1) text text text text text
(1) text text text text
Is much more practical and easy to apprehend.
I disagree, especially when “text text text” spans so much space that your footnote is now on another page than its mark, so you can’t read it right away when editing.
What you talk about is practical when viewing the document, and the fact is that with LaTeX, you can choose where you want to place your footnote, so it’s a plus.
I wish for a real model/view writing system, a bit like LyX, where you can see approximate formatting, but keep a strong structure that you can abstract from the view. However, LyX has an ugly UI, and I’m not going to limit myself to MLA latex bib style.
LaTeX with a good editor provides that, and groups like GUTenberg provide big libraries of styles to their members, which may contain what you want. Some of it is also available on the Web.
When you are a member, of course, some of their guru can tell you where to find what you are searching for.
You could have also included *Kile* which is another Latex editor. Even though it does not have a WYSIWYG feel, it is very powerful and easy to use.
Kile is an excellent way to shorten the LaTeX learning curve and reduce syntax errors. I do agree with Anonymous above that seeing the formatted output as one writes is very helpful, though. How many Web designers do you know who upload raw HTML to the server without having first previewed it? Didn’t think so.
What would be nice is a LaTeX editor like Kile with a split window, one showing the raw LaTeX code, the other showing a WYSWIG version of the same code – interpreted and updated in real time, or, if that is too much of a cpu hog, updated every few seconds.
-Gnobuddy
>What would be nice is a LaTeX editor like Kile with a >split window, one showing the raw LaTeX code, the >other showing a WYSWIG version of the same code – >interpreted and updated in real time, or, if that is >too much of a cpu hog, updated every few seconds.
Real Time Updates of LaTeX Documents will hardly ever work. Even on an up-t-odate computer a complete LaTeX run will take 100% CPU and 100% load on hard disk for severel seconds.
What emacs + auctex however do, is to do real time previewing for selected parts.
Matthias
Once upon time, was FrameMaker. Its available on Windows and Solaris Sparc. It’s hands down the best writing tool I ever used. On linux, Kword is the closest I’ve come to Frame on linux.
I must second that…. used in on solaris and have found nothing that comes even close
I currently use texmacs to write all my papers
” On linux, Kword is the closest I’ve come to Frame on linux.”
Have you tried Scribus?
Once upon time, was FrameMaker. Its available on Windows and Solaris Sparc. It’s hands down the best writing tool I ever used. On linux, Kword is the closest I’ve come to Frame on linux.
Also it used to be available (and perhaps still is, depending upon whom you ask) for AIX, HP-UX, and other UNIXes.
I believe that there was even a Linux version kicking around at one point.
Of course there was also a Mac version, but Adobe killed that off as part of it’s apparent systematic destruction of FrameMaker. Now that it’s no longer fully cross-platform across the three main platforms that big publishing houses need, it’s not as viable a product anywhere.
I really get the impression that the Adobe folks just don’t “get” the idea behind FrameMaker. Anyone wishing to write an open source app to create books would be well advised learning the ins and outs of Frame though to see how to do things properly.
Not so long ago I read an interview with the author of a nifty program called Kdissert – http://freehackers.org/~tnagy/kdissert/
I believe that kdissert is close to TreePad in concept since it is some sort of mind-mapping tool but its main purpose is to generate proper structured documents in several formats such as pdf documents (based on LaTeX : article, book), pdf presentations (based on LaTeX : Beamer, Prosper), text processing files (OpenOffice.org Writer), plain text and internet documents (html) that you can open and edit later with your favorite editor or word processor.
Since you start adding content as shapes on its canvas and then link these shapes to each other, you can use this feature as some sort of “visual” outliner.
I haven´t spent too much time playing with it but I´ve seen some of the documents that it can output and was quite impressed.
DeadFish Man
Just a note for latex/lyx users.
There is a good program called latex2rtf,
which you can use for handing over latex
documents to word users. It’s a shame
that this is a one-way process though
Where is AbiWord? With it you get .doc compatibility plus a familiar interface (like MS Word). In my always humble opinion, it is better than Kate, although I do like them both. I appreciate your article. Thanks.
anyone out there got experience of moving from WYSISWYG to DocBook ?
I am thinking of moving a team of software developers away from Word but nobody wants to invest much time learning new tools.
I am convinced that DocBook is a better format (can track changes via source-control, generate multiple output formats etc.) but my boss thinks we haven’t
yet reached the critical mass (since nobody spends more than 3 hours a week wrestling with the WYSISWYG word processor).
thanks,
Richard
DocBook quite good for technical documents in the domain of software. It has many elements specific to this domain, for instance ‘command’, ‘screen’ and ‘programlisting’. Since it is plain SGML or XML, it can easily be edited by many XML editors or text editors.
The primary thing that I do not like about DocBook is print output. There are basically two ways to go: making JadeTeX output with jade and the DSSSL stylesheets. You can then use the JadeTeX TeX macros create print output in various format. The layout is consistent, but often requires manual editing before it is printed. Being able to edit Postscript directly is very handy in this proces.
The other route is to use the DocBook/XSL stylesheet to generate XSL-FO output. XSL-FO can be converted to various output formats. The last time I tried this, the print output was really suboptimal, with a lot of characters that dissapeared, etc.
Other than that the DSSSL and XSL stylesheets for (X)HTML work very well, and the output can easily be customized.
I did som jumping between word, latex and docbook on a school assignemnt with three class mates completley new to anything but word.
They all thought that latex was neat and didn’t mind working with it. This was a non-techincal document though, so nothing fancy.
Docbook just went way over their heads, and I didn’t like all the trouble to get it to print either. vex for eclipse was a nice editor though.
With booth aproaches I forced them to use subversion to add changes. On each update the server would generate a pdf and publish it (and a generation log) to a webserver.
The nice thing with this is that I could handle anything they didn’t understand. If there where errors in their latex I could just add another update to fix it for them. So the learning curve with latex was rather gentle.
… to set it up:
– enable hyphenation in the language settings (why is it there, I don’t know). It will allow better justified alignment, without those ugly big spaces. And no box overfull to be afraid of!
– clean up the styles. Only keep the handfull you need
– remove all physical formatting icons and add icons for the handfull of styles you use
It is not the perfect tool but it can actually handle large documents. Trimming down the styles and formatting allow to focus on content. Revisions is a great feature.
” On linux, Kword is the closest I’ve come to Frame on linux.”
Have you tried Scribus?
Which is noting like it at all, except you can make grate looking documents in both. Scribus is like Page Maker, not Frame Maker. The workflow is very different in those applications.
A fan of PuppyLinux has rolled his own NaNoWriMo edition of the pup, with a bunch of tools for writing.
It includes a wiki, which no one has mentioned here.
I am surprised that one of the best book writing tools (IMHO) was not mentioned.
http://www.texmacs.org
Screenshots:
http://www.texmacs.org/tmweb/home/screenshots.en.html
“I am surprised that one of the best book writing tools (IMHO) was not mentioned.”
Yes, its a good point. Its a nice package and a real alternative, and probably should have been included. Lyx got the focus because I got started with it first, and found it was well accepted.
Quote:
There are drawbacks to Lyx… For example, if you have picked a list format, then each paragraph will be a new list element.
This isn’t quite so. When using a list style enter the following keystrokes:
Return (start a new list item)
S-M-Right (Layout / Increase Environment Depth)
M-p s (switch to standard paragraph style)
Terminate subsequent paragraphs with M-Return to stay in the nested environment
S-M-Left and switch back to your list style to start another item
It sounds complex but generates simple LaTeX.
I don’t know anything about TexShop, but you might try Kile on Linux.It’s a TeX/LaTeX editor with syntax highlighting, command completion, etc, etc.
-Gnobuddy
The LaTeX people seem to be living in some kind of fantasy world where there are only 256 code points.
Repeat after me: There is no such thing as “plaintext”.
All text in a computer is binary, and programs need to know how to translate that binary into code points, and editors need to know how to translate code points to glyphs. It’s copiously stupid to assume that a text file uses whatever the current user happen to have currently as his/her default encoding.
I would recommend looking at this tool. It takes a simple “mind map” layout of paragraphs. Inside each box is a title/heading and the content for the section under that heading goes in the text area of that box.
From there you can generate a document in tex, OO and other formats. It is still an early development tool but quite useful in its simplicity.
For my writings I use txt2tags (txt2tags.sf.net), emacs (with outline mode) and subversion to store all my files…
—
Stefano Spinucci
“…to get the most out of any of these tools, your author will need a good, large flat screen, 19 inch minimun (sic) …”
I love these “at least” recommendations. When 14″ screens were the most common size around and 17″ screens were a real luxury, many people would recommend “at least” a 15-inch screen, although lots of people got (and still get) their jobs done in 14-inch screens.
Some time later, it was easy to find pundits saying that one needs “at least” a 17-inch screen to get anything done. As if.
Now we need 19-inch screens “minimun”… Although I write translation work with three programs running at the same time in a 17-inch screen and have no problem with that.
How long until we need “at least” the Times Square screen in our rooms to get anything done?