Just why?
I sometimes think why can’t Libre sort out even basic functionality for years …
I want to have a caption like “Fig. 1: bla-bla” and cross-ref in-text like “see Fig. 1”.
This box is somehow special and category names have a restricted syntax. Edit your question or comment to explain why you want to have a dot there (expected result). Text in the “Caption” box is unrestricted.
Yes, of course it’s a “feature”, I know …
The “Category” name defines an underlying variable and, as such, must abide by the syntax rule. It is composed of ASCII letters, underlines and digits. Of course an appreciated feature would be to make a difference between this variable and how it is displayed. But the majority of users would be confused by it…
If you accept a non user-friendly workaround, the restriction on the category can be relaxed, but you’ll have to do it manually for every caption (after all what you put in the “Caption” box is manual).
-
Insert your caption as usual but choose Category
[None]from the drop down menu. -
When the unnumbered caption is inserted in your frame, picture, …, put the cursor at the beginning of the line and type
Fig. :or whatever you want. -
Go back where the numbering should be and
Insert>Field>More Fields,Variablestab.- In the Type list, select Number range
- in Select, choose inside which list the caption should be numbered (Figure for “Fig.” is a good choice). Note that this list is the same as Category in caption dialog.
- optionally, click on a numbering format.
-
OK, you’re done.
To show the community your question has been answered, click the ✓ next to the correct answer, and “upvote” by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!
In case you need clarification, edit your question (not an answer) or comment the relevant answer.
EDIT 2020-05-03
I submitted an enhancement request as tdf#132626 to add another field in the caption dialog to be used as the prefix in the generated caption instead of the Category name.
It won’t insert the category when referenced.
Jesus … Even such a simple thing is not implemented out-of-the-box in 2020.
You’re wrong! I took the precaution to use the number range dedicated to figures. When you insert a cross-reference to the figures, it works as usual with a small difference however.
The caption is not fully under built-in control.
-
Inserting the Reference to the figure will yield the full caption paragraph, i.e. the prefix (Fig.), the number and the “caption” itself, including the suffix appended to the number field. Reference is formatting-safe.
-
Numbering is the same because it interrogates only the number range variable.
-
Category and Number returns only the number because I bypassed the caption engine and it does not know I have added a prefix before the number
Provided you select the adequate reference (either the full caption or only the number), you should have no problem with cross-references.
After thought: captions usually don’t use abbreviation, so having “Figure x: this is a figure” is the common rule in books. But, it is frequent in text to quote references as “See fig. x”. The out-of-box engine copies without transformation the category which introduces a violation of capital use: a capital letter should be used only at the begin of a sentence (save for proper nouns). Consequently, in polished documents, you only insert the number to keep the liberty of caring for casing or abbreviating the category.
@ajlittoz I have no idea what you’re talking about. The method described CANNOT have an inline-reference a-la “Fig. XY” automatically – you will have to type that in. And no, abbreviations in captions are absolutely ubiquitous in literature
How do you insert references to figures? I use Insert>Cross-references
@ajlittoz Yes. This method won’t work. It can’t technically insert something like “Fig. XY” since the category is none. See here
I have no idea who came up with such a silly restriction that the name of the category may not contain anything but letters and digits.
Use Reference to insert the full caption paragraph. If you don’t like the initial upper case letter, use Reference to get only the number and add manually “decorations”. Caption Text in my procedure contains everything after the number, including the colon which may not always be desired.
As I commented, the category name defines a variable. Variable names are restricted. The shortcoming in the design is probably to not have allowed to attach a “human-friendly” label to it for use in the document.
@ajlittoz Are you a co-developer? Or know any way to get the developers’ attention to this issue? It really makes no sense whatsoever to have this kind of behavior of labels
I am no developer and have no connection with them. However I know how to submit a feature request. Your problem meets also a need for me. As such, I’ll write this feature request and link the reference in my answer. But …
Don’t expect a quick implementation. Developers are not that numerous and they struggle against really annoying bugs. So they’ll consider feature requests if they are easy to implement, meet a reasonable consensus with regard to utility and don’t break the existing.
It is already late here. I’ll then write this feature request tomorrow. Pondering about the words to use is always a sound activity.
@Rubi: a developer answered to the bug report. I’m presently discussing with him to isolate the cause of the problem.
By chance, did you type the dot on the keypad? I discovered on my Linux box that any character typed on the keypad was not accepted by the Category field, though the keypad is in NumLock mode. The developer does not experience the issue under Windows.
Thanks a lot! Yes, I can’t type in ANY character except for undescore and letters
@Rubi: I traced back the problem to an inconsistency in my Linux installation. I prefer the KDE desktop while Fedora defaults to GNOME. If the correct widget interface module is not installed, the problem appears. In my case, I had to force package “libreoffice-kde5” and all went fine. Caution, there is also a “libreoffice-kf5” which does not fix the issue.
A developer corrected the issue and backported the fix to 6.4. So it should be available soon when the updated version bubbles up in the distros.
I send a very special thanks to all developer because I didn’t expect such a quick fix. Especially on a tricky question of interfacing an external widget library.