Don’t try to transfer the styling/formatting, all the more if you used table “styles” which are not traditional styles but kind of a set of macros which get fired when you expect the least and repaint the whole table, erasing your custom formatting.
Either proceed cell by cell or use Table>Concert>Table to Text, copy the result, paste it into the new document and Table>Convert>Text to Table. Note that I did not test it on table containing several paragraphs in cells; it usually works well on simple table with single paragraph cells.
Then you apply your preferred styles, as usual.
This requires parsing techniques beyond the possibilities of regular expressions. I once helped a user on a similar request with an external personal tool: the document is saved as .fodt, the tool parses the XML and transforms it; the transformed .fodt is opened by Writer and this is done. Writing the required parsing rules for the tool is not elementary: it requires understanding how your citations are encoded and mastering formatting through the XML while preserving styling method.
If your book titles are taken from a bibliography, managing then through the built-in bibliography feature might be simpler as the citation can be somehow formatted. The price to pay is to enter all your book descriptions into the bibliographical database.
You must paste them anyway. The ideal approach is to apply a frame style to them. Be aware that mastering frame styles is a high-level sport. And direct formatting is even more devastating on frames than on other style categories. Designing “generic” frame styles, i.e. styles to be shared by many images, is difficult but extremely rewarding.
So if you have a deadline, I’d say, go for DF over images and accept that you’ll need to reposition some of them before sending to the print shop. In any case, prepare your images outside LO to crop, scale them and adjust their dot density. You’ll gain peace of mind if Writer has just to use them “as is” – and the file will have the optimal size.
If there is no deadline, pause and take time to learn frame styles. But this is not enough. Practice on a scratch document to discover the nasty annoying oddities of those styles.
Not only safe but recommended.
Built-in styles are examples of semantic styling. Their names were chosen to suggest usage. In addition, there is a global consensus about their use. Everybody understand your purpose when you say “I applied Body Text or Heading 1”. Generally speaking they are well configured.
And built-in styles are not “reserved” or “locked”. You can customise them to fit your needs or comply with your graphical charter.
Strong Emphasis does not bold text. It flags some word that the author considers to be more important than simple Emphasis. This can visually be translated in many ways. Developers opted for bold because is the typography tradition. But if you prefer to display a strong emphasis as red, you’re free to customise Strong Emphasis.
As an author, you must not think in italic, Roman, bold, reduced font size, colour, …, You must think in significance terms: main topic, comment, citation, note, important, humorous, understatement, irony, trademark, foreign word, …
So use the provided built-in styles. They are organised in “families” so that when you modify the family “head”, the change is forwarded to the members of the family (use the Navigator in hierarchical view to see the relations). When a style is considered “missing” for your purpose, create it attaching it to the ad-hoc family head so that it benefits the inheritance.
As I mentioned in another post, you rarely need more than 5 extra custom styles.
