Taming OpenOffice.org

A reader pointed me to issue 100262, where I learned a much better way to solve the problem with master documents described in this post.

Here is the secret:

1. Right-click on the first list item in the first list in the document and choose Paragraph, not Restart Numbering.
2. On the Paragraph dialog, go to the Outline & Numbering tab.
3. Under Numbering, choose Restart at this paragraph and 1 for Start with. Click OK to save.

Note: If you do not explicitly choose 1 for Start with, the setting is not retained!

This is a bit cumbersome, but works fine. Unfortunately I can see no way to build it into a paragraph style.

The problem

When custom numbering styles are used for lists, the first item in the first list in a file does not retain a Restart numbering setting when the file is saved.

When files are used standalone, this is not a problem, but when they are combined (as in a master document), the first list in each chapter continues its numbering from the last list in the previous chapter. To correct this, the first item in the list must be manually changed—but any manual changes in subdocuments are lost when the master document is updated.

The solution

Create a hidden section near the beginning of each document. Put one paragraph in that hidden section and assign your custom numbering style to that paragraph.

Because this first list is hidden, it does not matter if the number is wrong. Now when you select Restart numbering on the first item in the first real list in the document, that setting will be retained.

A reader left a comment on the draft of my self-publishing book with some detailed info about PDF export issues. With his permission, I’m copying that comment into this blog entry, so more people will see it.

*colorspace issue in pdf export*
http://www.openoffice.org/issues/show_bug.cgi?id=81097

(Actually – OpenOffice 3.xx – OpenOffice export as rgb colorspace even you use only black text)
this is a critical bug I can’t understand why developpers have yet fixed

due to this critical bug, your pdf will have same colorspace (RGB), so, you cannot print your ONLY-BLACK-INK book exported to pdf, with offset, RGB, causes RIP (pre-printing process) will make four plates Cyan-Magenta-Yellow-Black), instead one (Black only), now, typography must spend much money for every plate, so you must convert to grayscale before submit to offset print service. please, you have a great blog, I hope more people know about this bug, so developpers are constrained to fix (now they think very few people know this and they can avoid to spend time to fix)

We need ability of select between: BLACK- CMYK – RGB in pdf export for professional printing

I found recently a trick to convert RGB colorspace to grayscale for professional printing

with ghostscript, type (in Linux and Windown both) all over one line
gs -sOutputFile=output.pdf -sDEVICE=pdfwrite -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray -dCompatibilityLevel=1.4 input.pdf < /dev/null

NOW, in Linux, print via CUPS, seleting GRAY from OpenOffice print options dialog. this second choice, ever works fine, the first may have problems with pdf exported via internal pdf driver of openoffice, due to custom font encoding. In fact, once converted, with gsview command line, you see above, is not more searchable (because text encoding is puzzled, even viewing and home printing seems fine)

ANOTHER PDF related question is about font encoding:

*NEVER SUBMIT FOR PRINTING PDF CREATED WITH OPTION: JPEG compression*
I discovered some time ago, OpenOffice, when performs jpeg compression on images, also do something to font encoding, and if you try to select text portions, you will give garbage text instead of corrected text