[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Book review: Designing with LibreOffice

April 20, 2016

This article was contributed by Neil Brown

Designing with LibreOffice (DWL) is a new book by Bruce Byfield exploring the discipline of typographical design and how eye-pleasing results can be achieved with the LibreOffice (LO) office suite. Well over half of the considerable 500 pages are dedicated to creating documents with Writer, but slide shows, drawings and even spreadsheets need some consideration given to design and they are not ignored.

The target audience is anyone who creates with LibreOffice and wants their creations to look better, whether as a novice or a seasoned traveler wanting to make better use of a complex tool. Byfield provides a mix of objective practical advice and subjective personal preferences. Even when those personal choices seem different than what you might prefer, you will find them presented with sufficient clarity and justification that you'll be able to identify and name the things you want to change and the things that can be safely preserved.

Jack of all trades

DWL weaves together three distinct goals, each serving to support the other two. Primarily, as the title indicates, the book is about the style of a document, particularly the visual typographic style. The general approach to style that is encouraged is one of simplicity and uniformity. These abstract ideas are taken into various corners of the design process, with space given to font choice, use of white space, and page color, just to name a few.

With so many fonts available today, making a choice can become bewildering. To assist, Byfield spends time on both historical and structural details of fonts so that the reader will know the correct terminology and be able to ask the right questions to focus in on which of the available fonts might be most appropriate in a given setting.

On the question of white space, the reader again has options reduced through the dictum that all spacing, whether margins, indents, or vertical gaps, should be multiples of, or occasionally submultiples of, the baseline-to-baseline line spacing. It may seem strange to correlate horizontal and vertical space so closely, but to achieve the larger goal of uniformity some sort of rule is needed and this one certainly seems as good as any.

Page color may at first seem a confusing term as it has nothing to do with hue or saturation and is purely about shades of grey. Depending on details of the font, how thick various strokes are, and of spacing, what inter-character and inter-line gaps are used, the page as a whole can look lighter or darker. DWL encourages the designer to think carefully about this and to adjust spacing and font weight if necessary to get the result most fitting for the document. This is a simple example of how the design guidelines go well beyond thinking about what LibreOffice happens to let you do and very much into the realm of appearance independent of a particular enabling technology.

The second theme is of a gentle introduction and tutorial in using LibreOffice to create these well-designed documents. Throughout the description of what a document should look like there are step-by-step instructions on how to coax LibreOffice to produce that appearance. Sometimes, the steps given seem overly simplistic or obvious but, just as often, there are pointers to functionality that might be hard to find but is useful. This ensures that the text is useful to a broad range of readers. To get the most value out of the tutorial side of the book, it would be a big help to have LibreOffice open on a non-trivial document for experimentation. As the Open Document source for the book is available for download, it would likely make a good sample to experiment with.

Finally, DWL gives the impression that it could be quite useful as a reference guide, not only for referring back to those step-by-step instructions, but also for the various summary lists of points to consider when making a decision, such as choosing a font, making use of tab stops, or even the perfect positioning of superscripts and subscripts. Unfortunately, the lack of an index impedes this usefulness somewhat. The table of contents is thorough, but I had cause to look back to be reminded how to update the color palette and all the references to "Color" in the table of contents were to entirely the wrong sort of color, as discussed above.

Some things I learned

A persistent theme throughout the book is the importance of making full use of styles. The position presented is quite uncompromising:

You have two ways to design a document in LibreOffice: by manual formatting and by applying styles. Or, as I like to joke: the wrong way and the right way.

While a great many useful details are presented, I quickly developed the feeling that I was missing something. It was as though I couldn't see the forest for the trees, probably because I had some preconceived ideas about styles that were not a perfect match for LibreOffice and were not being directly challenged by the presentation in DWL. Eventually, all the pieces fell into place and, looking back, I can identify two ideas that would have been more helpful to me had they been introduced earlier and more explicitly.

The first is that styling can be introduced into a document either by value or by reference (though DWL doesn't use these terms). If we accept styling as a generic concept for giving a name to a collection of one or more specific styling decisions, then one of the simplest examples would be the creation a color palette: giving specific names to selected colors. These could provide corporate branding, or maybe there is a single color called "highlight" used to provide uniform highlights. These colors can then be included as appropriate into the document, but they will always be included by value, not by reference. If, after creating your document, you go back to your color palette and change "highlight" be a slightly darker color, the colors in your document will not change at all.

This styling-by-value also applies to the styling tables using "AutoFormat" and is an approach that can be very effective when creating drawings. If you want a number of elements in a drawing to be the same size and shape, this uniformity can only be achieved by creating an original and copying that value around.

Styling-by-reference is the more traditional form of styling. A "style" can be defined that specifies various attributes for a character, a paragraph, or a list item, etc. Each such object references a style from which it inherits attributes, and that style can in turn inherit from a parent style, and so on. It would be possible to create a "highlight" style that sets text color, rather than a "highlight" color as mentioned earlier, and have all styles that require highlighting inherit from this. That would make changing the highlight color easy.

There is a blurry line between by-value and by-reference styling when it comes to the use of external templates, and this might have caused part of my vague feeling of uncertainty. A "template" is a LibreOffice document much like any other, though with a slightly different name extension, and with no document content. What it does contain is styles. When you create a new document based on a template, the new document gets both a copy of the styles in the template and a reference to the template. If the template is subsequently changed, the reference allows new styles to be copied into the document with little effort, but it is always the copy of the styles in the document, not the ones in the template, that are used. So a template is quite a different thing than a CSS style sheet used with HTML or a LaTeX .sty file.

The other fundamental aspect of LibreOffice styling, which is only indirectly described in the text, is that it is really all about paragraphs. Without wanting to belittle characters and frames, or ignore pages completely, it is necessary to realize that when thinking about the structure of a document there are no chapters, sections, subsections, or lists. There are just paragraphs, some of which may look like chapter or section headings, and several of which might combine to create the appearance of a list. This aspect of LO styling [Tip] was made particularly apparent in DWL in the various break-out passages such as Tips and Cautions.

Each of these is structured with two paragraph styles, the first being a list item style, despite the fact that there is no list in sight. The need to place a graphic just before the introductory word "Tip" is easily met by defining a bullet list style with the chosen graphic as the bullet. A "Note - Tip" style chooses that bullet and sets the font, color, and positioning for the word "Tip". Then a "Note" style for subsequent paragraphs ensures that the body of the Tip appears in the desired place with the desired appearance.

There are two particular properties of a paragraph style that help to synthesize larger-scale structure out of what is really a list of paragraphs. A paragraph style can identify a "Next style" which will be the default for the next paragraph. "Note - Tip", as well as "Note - Caution" and others, identify "Note" as the "Next style". When the note is finished, the style must be explicitly reset to "Text Body". A paragraph style (typically for a chapter or section heading) can also be given an "Outline Level" which allows a hierarchical structure to be extracted from the document and presented in the "Navigator" dialogue. These two allow multiple paragraph styles to work together to provide the appearance of larger structures, but those structures are not imposed in the way they might be by an XML DTD (Document Type Definition).

While all this information is contained in DWL, the big picture is left for the reader to deduce rather than being spelled out.

A moment of self reflection

Being a book that discusses the style of (among other things) books, it seems unavoidable that the metrics given in DWL should be used to measure the book itself. On the whole it passes with flying colors, being pleasant to read and possessing a visual style that is distinctive without being distracting.

There are just two fonts, one for the main body of text and one for various break-out sections, and there is one alternate color, a muted green, used for various highlights such as section headings, page numbers, and list bullets.

The design guidelines repeatedly encourage the use of white space for separating distinct elements rather than more direct methods like borders or alternate backgrounds. While this seems to work well for the most part, there is one area where it falls down. The captions for the various screen-shots are set in the break-out font, are slightly closer to the screen-shot than to surrounding text, and do not have the first-line indented the way that body-text does. Nonetheless, several times I found myself reading those captions as though they were part of the regular flow of text, which was quite distracting. For me at least, a stronger contrast would help, even if it was just centering the caption text rather than left-aligning it.

Chapter 16 begins by acknowledging, and then discussing, the considerable difficulties involved in finalizing a document — correcting those issues that a word-by-word focus won't see, but which require a much broader perspective. In what can only have been a serious breakdown of the editorial processes, the book provides clear examples of what can go wrong. Chapter 5, "Spacing on all sides" contains two sections (at different nesting levels) named "Spacing between paragraphs". It is not just the name that is duplicated but also most of the text and even the caption of a screenshot, though it is a different screenshot in each case. While this is by far the worst lapse, there are two or three other places where text is needlessly duplicated. These problems don't really detract from the value of the book, but they do distract from focusing on the important issues.

For your bookshelf?

There is no doubt that DWL contains a wealth of information gained over years of experience. This information is conveyed in a coherent and approachable style. Even when it is not able to provide the complete and definitive answers we might want to get on with creating a document, it provides so many hints, pointers, and perspectives that it will doubtless set you on the right path to finding what you need to know.

DWL is licensed under the Creative Commons Attribution-ShareAlike license and can be downloaded in source or PDF formats, or purchased from a print-on-demand service. "Thank you" contributions from $2 to $25 can easily be made through the book's web site. For anyone who regularly works with nontrivial documents and wants to lift their game, or anyone with a general interest in improving their LibreOffice skills, this book would be a worthwhile investment.


Index entries for this article
GuestArticlesBrown, Neil


to post comments

Donate before you forget?

Posted Apr 21, 2016 8:38 UTC (Thu) by ncm (guest, #165) [Link] (9 responses)

I had meant to figure all of this out for myself, for years, but never quite got to it. In the meantime, I muddled along. This was just the right moment to send a donation big enough to make me feel that I had better get value for my money by actually learning the process. I sent $25; less would make it too easy to ignore.

I gather that it is possible to set a mode on a document file so that ad-hoc formatting is actually forbidden, in LO and in MSWord. Reports are that the overwhelming majority of really debilitating bugs in the latter are avoided in this mode. When you create a document for collaborative editing, and set this mode, it stops other contributors from from destroying the document structure and, not incidentally, from introducing mysterious bugs into your document.

Donate before you forget?

Posted Apr 21, 2016 17:12 UTC (Thu) by oever (guest, #987) [Link] (8 responses)

I gather that it is possible to set a mode on a document file so that ad-hoc formatting is actually forbidden, in LO and in MSWord.
That would be a very useful feature to have. I've never seen it in either application.

Donate before you forget?

Posted Apr 22, 2016 20:49 UTC (Fri) by nix (subscriber, #2304) [Link] (5 responses)

Having just converted a 250,000-word LibreOffice document into an ebook, I can only second this. All the style tricks above were needed to get something remotely tolerable, along with a non-default extension for XHTML export that has never been ported beyond LibreOffice 4.4, and HTML Tidy and extensive XML::Twig bashing on the result to get the thing remotely non-horrific looking (and more to translate the TOC into a nav document and in-book HTML TOC).

So that sounds like a lot of work, but that was the easy bit. Our worst problem by far was places where ad-hoc formatting had been applied. You can't search for it, and it's often invisible until you export it as something else (DOC, DOCX, XHTML): it lurks, waiting for the proofreader -- and, often, only becoming a visible problem on particular ebook readers, so merely proofreading it won't save you. What's worst of all is that there's not always an obvious way to *remove* such formatting. 'Clear Direct Formatting' only clears certain things. It will not clear e.g. regions where a bulleted list has been erroneously set and then "removed" by turning the bullet off, leaving the indentation visibly wrong but all the indentation parameters apparently fine. You have to already know or guess what the cause of a particular bizarre misformatting before you can tell how to remove it, and the absence of anything like WordPerfect's (or HTML's, or LaTeX's) system where all stylistic changes are really encoded as inline markup in the text stream makes it nearly impossible to even ask LibreOffice "why are you rendering this like this, differently from everything around it?" You have to grovel at random through dozens of dialog box panes until you find the one that is wrong, but you have to *know* it's wrong, because of course the thing is modal and you can't view corresponding formatting settings for two paragraphs at once.

After all of this, my opinion of using LibreOffice to typeset both books and ebooks is "never do it, even if the alternative is writing HTML by hand, in your own blood". It is manifestly, grossly unsuited to both tasks, and trying is an exercise in constant aggravation. (It is clearly not even tested at such lengths: merely saving the document took in excess of ten minutes on a quad-core i7, though the quad-cores were useless since the thing was only using one; autosaving was just as slow. Ten minutes, to save a 1.2 megabyte file! It's beyond a joke.

Still, LibreOffice did at least never corrupt its own savefile such that you couldn't get any content back out of it, even when it crashed because I was doing difficult and unexpected things like consulting the online help more than twice in a session, so it's still doing dramatically better than Word did when I tried to use it for a similar task, six or seven years ago.)

(The resulting book is at <http://www.charlottealdredbooks.com/>, though it couldn't be more irrelevant to the subject matter of this site if it tried.)

(The next book will probably be written in Sigil.)

Spotting direct formatting?

Posted Apr 26, 2016 9:35 UTC (Tue) by robbe (guest, #16131) [Link] (1 responses)

Would setting all styles to something undistinguished, like light-gray on white (or really tiny text), help with noticing direct formatting by letting it stand out much more?

Congratulations on completing this herculean¹ task!

¹ You decide whether it’s more like fighting a hydra, or cleaning stables.

Spotting direct formatting?

Posted Apr 26, 2016 10:44 UTC (Tue) by nix (subscriber, #2304) [Link]

Would setting all styles to something undistinguished, like light-gray on white (or really tiny text), help with noticing direct formatting by letting it stand out much more?
That was one of the tricks we used, once we had extracted the XHTMLization of the styles we actually wanted to use, then cleaned them up so they didn't refer to explicit point sizes or font names any more. (Before the final proofread I flipped the styles to microscopic black on black on black and then visually hunted for any regions still readable... but, of course, not all direct formatting affects font colour or size: none of that helped or indentation, or random bulleting, or random listifying, or a random font family change while keeping the size etc... I spotted most of those by visually scanning the XHTML, but I'm sure I missed some.)
Congratulations on completing this herculean¹ task! ¹ You decide whether it’s more like fighting a hydra, or cleaning stables.
Definitely a hydra. We'd fix one problem and five more would turn up. One particular irritation was Ctrl-F to search, which in LibreOffice 4.4 at least was kind of like Emacs isearch without all the useful features (like searching as you type: you still had to hit return). Half the time it missed the keystroke, and then whatever you searched for got typed into the document! Of course, since you were fixing errors at this point you'd probably go tsk and zoom off to the next error and oops now you introduced a problem rather than fixing one. Not a very good design (though it would have been reasonably OKish if the keystroke hadn't been randomly missed: only that keystroke seemed to be missed, so it was probably a bug in the then-new non-dialog-box find system, probably long-fixed, too).

Donate before you forget?

Posted Apr 28, 2016 3:31 UTC (Thu) by lordsutch (guest, #53) [Link]

One thing that might help for tracking down formatting oddness is saving the document as a Flat OpenDocument file; in that format you can usually track down presentational markup ("manual styling") once you know what XML to look for.

I've ended up doing this manually with documents that ended up in some weird formatting state (usually due to imperfect Word -> LO conversion); with XML processing tools you could probably automate a lot of the basics though.

Donate before you forget?

Posted Apr 29, 2016 7:19 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> You have to already know or guess what the cause of a particular bizarre misformatting before you can tell how to remove it, and the absence of anything like WordPerfect's (or HTML's, or LaTeX's) system where all stylistic changes are really encoded as inline markup in the text stream makes it nearly impossible to even ask LibreOffice "why are you rendering this like this, differently from everything around it?"

I'm a constant pain to the other LO devs by asking about this, but there is currently a massive clean-up of LO's internals going on. Hopefully this will soon mean it's possible to implement a "reveal codes" view of the document - at present the LO internal layout is (still) a bit of rats-nest. It's annoying - the document structure is nice and clean, but the program itself is still carrying a lot of technical debt.

Cheers,
Wol

Donate before you forget?

Posted May 10, 2016 20:39 UTC (Tue) by nix (subscriber, #2304) [Link]

That's excellent news! More power to the people working on this!

Donate before you forget?

Posted Apr 26, 2016 6:58 UTC (Tue) by ncm (guest, #165) [Link] (1 responses)

Bruce, is there such a document mode in LO? Everything I know is hearsay.

I do recall seeing an article about such a feature in MSW.

Donate before you forget?

Posted May 5, 2016 18:40 UTC (Thu) by nanday (guest, #51465) [Link]

If you use styles, there's no need for a document mode. The Organizer tab for a style summarizes the format, and from there making changes is trouble-free.

What you need to remember is that LibreOffice was designed for use with styles.

Book review: Designing with LibreOffice

Posted Apr 22, 2016 1:05 UTC (Fri) by nanday (guest, #51465) [Link] (2 responses)

Thanks for the thoughtful review!

I agree with you that the captions are not ideally positioned. My own preference would be to separate them from the main text with more space. However, the problem highlights another fact of design: you rarely get to design without other considerations affecting your choices. The truth is that adding that extra space added another 3o pages to the current 514, which simply couldn't be justified.

There is also at least one other major design element in which my preferences had to step aside for the formatting required by Lulu.com.

I'm going to add the comments in this review to my list of possible revisions. However, after three years of work, my editor and I are probably going to wait at least six months to bring out the revisions. I thought I knew something about publishing, but I've learned that there is a world of difference between developing 1200 word articles and a 90,000 page book.

Book review: Designing with LibreOffice

Posted Apr 22, 2016 5:09 UTC (Fri) by nanday (guest, #51465) [Link] (1 responses)

That should be 90,000 words, of course. It only seemed like 90,000 pages.

Book review: Designing with LibreOffice

Posted Apr 22, 2016 20:51 UTC (Fri) by nix (subscriber, #2304) [Link]

... whenever you were waiting for it to save. :)

Book review: Designing with LibreOffice

Posted Apr 23, 2016 1:06 UTC (Sat) by dlang (guest, #313) [Link] (3 responses)

any chance of the book being available in .mobi or .epub? the website only lists .pdf and .odt

those can be useful for many purposes, but something that's easier to read/search on portable devices would be nice.

Book review: Designing with LibreOffice

Posted Apr 23, 2016 17:03 UTC (Sat) by nanday (guest, #51465) [Link] (2 responses)

One person has volunteered to convert to .epub, but it's a slow process, because it basically means reformatting the entire book. The trouble is that .epub only supports very limited formatting, so an .epub version is much more difficult than exporting ODT to PDF files. That means that an .epub version means supporting two different versions of the text, which can be nightmarish for the publisher.

As for .mobi, anyone who feels inspired to undertake the effort should contact me or Jean Weber, the publisher. We can probably work out a profit-sharing agreement.

- Bruce Byfield ("nanday")

Book review: Designing with LibreOffice

Posted Apr 25, 2016 8:27 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

Well, the reason that .epug, .mobi, and .html don't give you as much control as .pdf does is that you have no idea what page size, pixel dpi, or font size the reader is going to be using. Under these conditions, trying to have absolute control over how the book looks is not only an exercise in futility, but is sure to produce horrifically bad results under many conditions.

you actually need precise control for your examples, you will have to have them be pictures in the text.

There are lots of free tools out there, with many people reporting very good results with calibre

Book review: Designing with LibreOffice

Posted May 6, 2016 19:24 UTC (Fri) by nanday (guest, #51465) [Link]

Unfortunately, none of the free tools change the fact that .epub and .mobi are very simple formats, or do much to reduce the effort involved. So it's going to take a while.


Copyright © 2016, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds