I reloaded the document once again to make sure. I confirm there is no Set variable field in it. This can be asserted both with View
>Field Shadings
and the Navigator Fields section.
-
To see the variable inside the ODT document, go to Insert > Field > More Fields > Variables > Type > User Field. You’ll see “boxed” there; it is set to 1.
-
To see the field rather than the interpreted text, go to View > Field Names. You’ll see that the field between the square brackets reads:
Conditional text boxed == 1 : boxed in : set free
-
To see the conditional-text field, highlight the text between the square brackets and double-click. You’ll see the same box as in the image.
EDIT: I see the field in the Navigator. I don’t know why you don’t?
One ugly workaround in the mean time could be to save the document as Flat XML fodt. Open in a text editor, then search the opening and closing tags for conditional text <text:conditional-text …> and </text:conditional-text> and replace with an empty string. This leaves the text (as it was when saving the file) behind. Open back in LO from where you can export to epub.
This would obviously more easy if Writer had a function to convert fields to text. The official way to do so now is to select the text of the field, cut and paste back as unformatted text. Handy for your sample document, but not if there are tens or hundred fields to change.
You could even do the replacement in Writer after opening the fodt file as plain text (add a .txt. extension). With “Regular expressions” checked:
Search: <text:conditional.*?>(.*?)</text:conditional.*?>
Replace: $1
“Replace all” and you are done. Save back as plain text.
That workaround is a fantastic temporary solution, thank you!
I shall use it in the meantime.
Am I correct that the only differences between .fodt
and .odt
are that .fodt
is a single file and it doesn’t use compression? (I know that .odt
is a file containing compressed files.)
I am afraid this is not the intended usage of this field because, though created, it is not present anywhere in the document. How do you change its value?
I see the conditional text field but not your user entry field. It appears only after I insert it. So how do you force a different version of the text when you have no “control” field in the document but only “using” fields?
Usually in such a document, you have a bunch of invisible (hidden) paragraphs at the beginning with text explaining the role of the variables and a variable field.
Built-in help explicitly mentions insertion of a Set variable field before using a condition.
Set variable and user entry fields are seemingly absolutely equivalent. They both create a variable and both are edited with a double-click.
The procedure is given in built-in help: copy the field and paste it back as Unformatted Text. It will show the alternative selected by the variable value.
No, these files are not equivalent. I have seen that for OLE objects some information is not preserved, and the objects are incorrectly restored when opening such file.
Note that I also wrote:
The official way to do so now is to select the text of the field, cut and paste back as unformatted text. Handy for your sample document, but not if there are tens or hundred fields to change.
I am afraid this is not the intended usage of this field …
Uh, yes, it is! It’s documented in the official help.
To answer your questions:
How do you change its value?
- Insert > Field > More Fields (on my system, the shortcut is Ctrl+F2, but I don’t know if I changed that) > Variables > Type > User Field > Select > select the variable.
- At the bottom of the dialogue, you can see the name and the value. Change the value and press the green tick.
- Close the dialogue.
- Tools > Update > Update All (the default shortcut is F9).
I hope that this answers all of your concerns.
The procedure is given in built-in help: copy the field and paste it back as Unformatted Text . It will show the alternative selected by the variable value.
@Vanadium already mentioned that. Unfortunately, it isn’t useful for my document, which has around 300 such fields; it would take an unacceptably long time, and I’d have to repeat the process each time I changed the variable.
The solution that @Vanadium gave is quick, so it’s an acceptable workaround.
No, these files are not equivalent. I have seen that for OLE objects some information is not preserved, and the objects are incorrectly restored when opening such file.
Thanks, that is important information. I have made a note to be careful not to overwrite the original when following your procedure!
@PaddyLandau: the fact that you didn’t insert a user entry or set variable field from scratch is IMHO a logic mistake. Having these “control” fields grouped at start of text will draw attention on the “dynamic” nature of your document.
If you put into unprepared hands, users won’t guess they need to modify it by inserting a control field. In addition, I bet not many users know the trick to make these controls fields not visible in the final copy.
So all in all, your document should be ready for showing variants. The only needed procedure step should be the double-click on the variable.
the fact that you didn’t insert a user entry or set variable field from scratch…
I don’t know why you keep insisting that I didn’t set it up from scratch. There’s no other way to do it. You have to set it up from scratch. I literally followed the official instructions to do what I did, albeit that this was first set up over 10 years ago.
It works very well. Why would you think that it’s wrong to do this? I have two different target audiences. I change the variable for one audience, just the once, and press F9, and the entire document updates in under a second. I export my PDF or EPUB. Then I change the variable for the second scenario, again just once, press F9, and export my second PDF or EPUB.
Now I have the two versions that I need, one for one audience and one for the other audience.
Having these “control” fields grouped at start of text will draw attention on the “dynamic” nature of your document.
Only if you have the ODT copy. But that’s not the copy for distribution. The resulting PDF or EPUB is the one for distribution, as I say, for two different target audiences.
If you put into unprepared hands, users won’t guess they need to modify it by inserting a control field…
Correct. That’s why I wouldn’t do that.
Update: I have found that EPUB export leaves other fields within the document are left empty, e.g., cross references (e.g. heading text), document information.
I think that I have no choice but to find a solution that doesn’t involve EPUB. That could be difficult, unfortunately, but I’ll figure it out.
These are issues with the current implementation of epub export. On the other hand, there are cases where exporting a field result makes no sense, for example a cross reference that refers to a page number.
Also here, a same trick could be applied (“text:bookmark-ref...…</text:bookmark-ref>”). Alternatively, you could try to convert fields to text before exporting to epub. Unfortunately, LO does not allow to do this automatically (the official way is to “cut the field and paste it back as unformatted text”, so one by one…).
Code that should do this is fiven here: Find field, replace by plain text, keep formating - #2 by ajlittoz
Thank you, @Vanadium . This is getting too complicated, so I shall probably have to stick with PDF.
Intuitively, I would have thought that a cross reference should work, if the page number itself, because clicking it would allow you to jump to that point. Oh well.
Thanks, I’ll do that.
As a possible workaround, Calibre can convert .odt to .epub - might be worth a try.
It’s taken me a while, but I’ve just tried Calibre (version 6.16.0), and I am impressed. It does a competent job of converting a large .odt document into .epub.
So far, there are some small problems, the most important of which is that it doesn’t restart numbering where required for numbered lists. I don’t know how to fix that.
Thank you for the suggestion.
it doesn’t restart numbering where required for numbered lists.
Numbered lists are quite tricky if you want to do it right (semantically right, I mean). If your lists are numbered with Format
>Bullets & Numbering
or equivalently with toolbar buttons, they all fall in the same “semantic domain”. This way of numbering items is a complimentary service offered to Word switchers, supposed to ease conversion to Writer. Since it is inspired by M$ Word, it has many quirks to make it usable by newbies. Consequently it is prone to many hazards.
The rigorous method of numbering goes through list styles but the theoretical notion of list is difficult to grasp in the beginning. And list styles are not easy to tame!
The rigorous method of numbering goes through list styles…
Thanks for the reply, @ajlittoz. I am indeed using a list style for all of my numbered lists, because I want them all to have the same format, and of course to make it easy if I need to change the format later.
I’ve been using “Restart numbering” for the first item in each list. It works perfectly in LibreOffice but not in the generated EPUB
I’ve been looking at the file contents.xml
, and I see that the subsequent lists always have the attribute continue-list
. Quite bizarrely, there is one list (again, with the same list style as all the others) that doesn’t have this attribute, and so it does restart from 1 in the generated EPUB. But I can’t figure out how I managed to do that! I can’t reproduce this.
I’ve reported the bug with Calibre. In the meantime, I’m thinking of using a pseudo-list style, where I outdent the first line of each paragraph so that I can manually number each list. It’ll be a pain, and I hope that I don’t make a numbering mistake (there are quite a few lists in the document) — it also prevents using an automated reference to a list item in the document — but I don’t know how else to do go about this.