Ok, well I think that that’s enough background. It’s time we actually did something useful. The first step we are going to take is to prepare your manuscript in LibreOffice. Depending on how you wrote your novel this might just be a case of few minor tweaks or it might involve a fair bit of work. The thing that is important is whether or not you formatted your novel using styles. For the sake of simplicity, I’m going to assume that you didn’t and that you don’t have clue what I’m talking about. If you did use styles, just use this section as a check-list.
So what are styles? They can be thought of as the poor cousins to XML tags and CSS style rules (discussed in the intro to XML and CSS). That is to say they can be used to both define sections of your LibreOffice document and describe how these sections should be displayed. They have two parts: the style definition (similar to the way CSS defines styles) and application (similar to the way in which XML tags divide your work into logical sections).
However, compared to CSS, LibreOffice’s styles are really limited. The first shortcoming you’re likely to spot is the limited number of options available to LibreOffice’s style rules. However, more annoying in practice is the fact that LibreOffice doesn’t have any cascade and only very limited inheritance. With a bit of thought and planning these drawbacks can be worked around, but what will have you pulling your hair out are direct styles and formatting. This is formatting that LibreOffice ‘helpfully’ creates for you, and if you are not careful, it will very subtly screw up your e-book conversion. We will deal with this latter on in this section.
Some of you out there might remember I said earlier (or might already be aware) that LibreOffice’s ODF format uses XML, so you might be a bit confused by me saying that LibreOffice’s styles do the same job as XML tags, as, surely, the file already has XML tags, and what’s more, if it is XML based, why doesn’t LibreOffice just use CSS (or XSL-FO)? The answer to the first of these two related questions is yes it does use XML, but for better or worse, LibreOffice uses a flat XML format.
A flat XML format is one where the XML hierarchy is collapsed to just one level. If this sounds complicated, it is only because I’m explaining it badly. Hopefully a quick comparison will clear it all up. Here is an example of fairly normal XML document:
<example> <person> <name> <first>Robert</first> <middle>A</middle> <last>Wood</last> </name> <profession>Writer</profession> </person> <person> <name> <first>Ann</first> <last>Example</last> </name> <profession>Scuba Diver</profession> </person> </example>
And here is the same information encoded in a flat XML file.
<example> <first-name>Robert</first-name> <middle-name>A</middle-name> <last-name>Wood</last-name> <profession>Writer</profession> <first-name>Ann</first-name> <last-name>Example</last-name> <profession>Scuba Diver</profession> </example>
These two files both contain the same information, and they can be converted to and from each other fairly simply using XSL. However, the ‘flat’ example is clearly evil and should be burned at the stake. LibreOffice, though, goes one step further down the path to hell. Its file format is more akin to the following:
<example> <para style=“first-name”>Robert</para> <para style=“middle-name”>A</para> <para style=“last-name”>Wood</para> <para style=“profession”>Writer</para> <para style=“first-name”>Ann</para> <para style=“last-name”>Example</para> <para style=“profession”>Scuba Diver</para> </example>
As you can see, if it wasn’t for the style information, we would have no way of telling that our second person had omitted their middle name, as all we would have would be a mess of para elements. But this is pretty much what LibreOffice does, and it is not going to change any time soon, so we need to accept it/drink copious amounts of alcohol until we forget about it and move on with our lives.
However, no amount of alcohol could dull the pain of style inheritance in LibreOffice. The way it is implemented is enough to have you scooping out your eyes with a spoon. In short, inheritance works backwards i.e. rather than children inheriting from their parents, parents inherit from their children.
To a certain extent this is an inevitable result of the flat XML format: as there isn’t any hierarchy in the structure of the document (as everything is on the same level), it is impossible for inheritance to work normally (as nothing has any parents or children). However, I fail to believe that the solution implemented by LibreOffice’s styles to this problem is the best one. But again, realistically, we aren’t going to be able change this, so we had better try to live with it.
The net result of this backwards inheritance is that, as you will see shortly, when defining your styles you have start with the youngest child and work your way back up to the greatest grandparent.
All this goes some way to answering the second question posed earlier (i.e. why CSS or XSL-FO aren’t used by LibreOffice), as without a coherent hierarchy of elements in the XML document, most of the features of these technologies wouldn’t be usable.
Before all this annoys me too much, we need get going, but before we begin we are going to have to do a bit planning, as, though the way we are setting up LibreOffice means we will be able to change the formatting, we need to pick some sort of formatting to begin with and it makes sense to pick an initial formatting that is pretty close to what we want to end up with. Also, because of the backwards way style inheritance works, we need to plan which styles are going to inherit from each other.