Curly brackets issue with xml or html Save As or Export?

{{KEYWORD}} is the formatting convention used by Mustache templating and GNU Recutils recfmt to recognize where to copy a value.

While developing a script in bash to create and send receipts I needed to save ODT created with LO in a plain text format for the above.

First I tried Export in XHTML. Keywords replacement as next step worked well at first but at second try not anymore. Then after Save As FODT flat XML replacement didn’t work at all.

Found out the first attempt worked because I added the curly brackets after exporting. With the Mustache formatting already in Export and Save As introduced some tags in between KEYWORD and the curly brackets. Rendering the recfmt template no longer valid.

Are double curly brackets reserved characters for some internal LO function? I found in this forum multiple references for Math.

Thanks for sharing.

Any reason not to save as plain text? There is a filter to save as text with choice of charset. I’m using this since several years without problem. But I admit, we use only single { }.

Perhaps formatted text without binary blobs is a more accurate description. ODT is not accepted as input by GNU recfmt.

XHTML or FODT to preserve formatting, publishing settings and one embedded image. Does this fit in a plain text file?

Usually not, but “embedded images” is also not a common (often used) feature in html. Usually we set links instead of encoding the blob as text (wich is long possible - I remember UUEncode …)
.
So formatting is all complex stuff possible with Writer like different fonts, sizes, styles etc. Then you need fodt. But as Writer was not designed as code-editor there may be (is) trouble ahead. Who reads generated xml/html wil often find inserted SPAN-Tags wich may depend on the way you insert {{

Can you post a small sample .odt ?
Show the curly braces other formatting than the data inside the braces?

Actually I just type them around the keyword. Nothing fancy. My best plan for now is to Save As FODT without the curly brackets, open it and add them by hand. Save.

I will try to prep a shortened version as it is a biz document. But you may easily try it yourself with any document I think.

As attachment the original document. I just replaced all characters. LO 7.4.7.2.
Saved As FODT double curly brackets are not kept attached to keywords. As example:

{{</text:span></text:span><text:span text:style-name="Car._20_predefinito_20_paragrafo"><text:span text:style-name="T8">XXXXXXX</text:span></text:span><text:span text:style-name="Car._20_predefinito_20_paragrafo"><text:span text:style-name="T10">}}

test.odt (42.1 KB)

Blame yourself. Your sample file is an horrible mess of direct formatting, though you seem to know how to use styles (even character styles).

Start by removing direct formatting and superfluous character styling. The idea is to avoid applying any formatting change on the {{KEYWORD}} sequence, even if it looks weird on the screen. It does not matter for your replacement which looks for a specific sequence without any formatting directive. Stream down your formatting. To summarize, a paragraph style is applied. Arrange for absolutely no extra styling or direct formatting when you meet {{KEYWORD}}.

And when this is solved, eliminate the nonsensical vertical spacing with empty paragraphs or line breaks. Vertical spacing should be done with paragraph style parametrisation.

1 Like

Thank you for looking at it.

This may become an interesting learning experience. Not for the reason you may imagine though.

You seem to expect I am having some knowledge of DTP. Why is that?

Also you seem to expect me to understand what you are writing about LO. I can look it up, of course, but it is beside the point. I don’t. I recently played a bit with groff’s tbl format and wrote my master thesis, long ago, with LaTeX. But I am still deeply ignorant about the subject matter.

Or you may simply employ descriptions accurate in your line of business / tech expertise. Same as I do when trying to properly circumstantiate a problem and describe a solution within my area of expertise. Because that’s is how we do it. I can relate to that. But in this case I am oblivious of your effort. Besides realizing the presence of some deeper technical issue.

Finally file is not mine. Judging by the biz history, file was duplicated from a duplicate of a duplicate. Then transformed to a Mail Merge format. And further edited. I couldn’t make it work. Ignorance about LO and other issues with fields and values. Then I myself deleted the Mail Merge bits, copied and pasted text in a new file. And fixed it from that. Because after all it’s the appearance they want.

Vertical spacing was added that way because of the HTML export. I actually forgot about it. Thanks again.

Because the document contains a lot of formatting through styles which is the intended way of driving Writer. However, this departs from the (poor) principles in M$ Word where most of the job is done with direct formatting. Consider styles are a lower-end static equivalent to LaTeX macros.

This explains the formatting mess. The best you can do is restart from scratch with strict rigorous formatting method. But you’ll need to read at least the Writer Guide for an introduction to the style machinery.

Then you could design directly your document as HTML. Writer has an HTML mode. But it tries to mimic its document formatting functions and IMHO the result is not always optimal from a CSS point of view. After all, Writer is intended to format text “for-print” documents, not general HTML ones.

It was a long journey. Was expecting Styles’ UI to mimic direct formatting’s. Widget button and drop down list. Took me a while to realise had to fiddle with the side panel instead to switch view and create a new style. With that achieved the rest is relatively simple. Got it right on Calc first so there is where I am using it now.

With the concept of CSS now applied to Calc formatting, and thus style cascading to everything, I now wonder how to apply the same concept to formulas. Array formulas perhaps? Quite complicated to apply though. {=MAX(0;(A2:A18-5)/3} as example doesn’t work. And defining them via wizard or keys combo is not exactly matching the more common experience with direct cell formulas. Again.