Adding a caption with menu Insert > Caption creates a caption with the following elements (in order): - a prefix, coming from the Category field of the dialog (followed by a space) - a number, coming from the number range whose name is given in the Category field - a colon, automatic insertion (followed by a space - a legend, coming from the Caption field The Category name is a variable name (used to define the number range) and as such is limited to ASCII letters, digits and underlines. This is not satisfactory in many languages whose common characters are outside ASCII, like many European languages (with diacritics), Greek, Russian and all Asian languages. As a contrived example, it is impossible in French to define a Décoration (Decoration) category because of the acute accent. In English, you can't use the abbreviation Fig. for figures because of the dot. The behaviour as described here is the same in all known versions of Writer implementing the Caption feature. The workaround is to use category [None] and to modify the resulting caption: - add Fig. and a space at beginning of the paragraph - Insert > Field > More Fields, Variables tab, Number Range and "Figure" - add a colon and a space This workaround results in the correct caption, but it can't be used in cross-references: - only Reference which returns the whole paragraph has the expected result - Category and Number just returns the number because category was set to [None] and is thus equivalent to Numbering - Caption Text returns everything after the number, i.e. it contains the colon and space, which is different from the "standard" case. IMHO, this could be fixed if the caption dialog contained an additional editable field Label (or whatever name you like), initialised with the category name but user could change it for whatever text he deemed fit for the document. This Label value would be used instead of the present Category name as the caption prefix. An English author could then use Fig. for the captions related to the Figure number range, a French author Décoration for the same Figure number range, etc. Depending on how it is implemented, I wonder if it could be possible to manually edit the generated caption prefix (in the frame, not in the dialog) so that we could have Figure for short captions and Fig. for long captions without losing the connection with the Figure number range and still capturing the current prefix in the cross-references. But this is secondary with regard to the specification above. This enhancement is a follow-on to question https://ask.libreoffice.org/en/question/241962/cant-type-dot-in-caption-category/ on AskLO.
I can't confirm this with Version: 7.0.0.0.alpha0+ (x64)Build ID: 8c8b3a4f83f67882b284ddc3b3fe10d3fe6dedf4CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GBCalc: CL It's possible to type Fig. instead of Figure into the dialog. So please Please provide a clearer set of step-by-step instructions on how to reproduce the problem. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided. Please paste also informations from Help => About LibreOffice. Thanks.
Version: 6.3.5.2 Build ID: 6.3.5.2-5.fc31 CPU threads: 4; OS: Linux 5.6; UI render: GL; VCL: gtk3; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded I insert a frame and then Inert>Caption. Iselect "Figure" from the Category drop down menu and erase "ure". Whenever I type a non-(letter+digit+underline) character, the full category name is inserted instead: Fig ("." typed) -> FigFigure Is there a change here between 6.x and 7.0 series?
Tested with Version: 6.3.5.2 (x64) Build-ID: dd0751754f11728f69b42ee2af66670068624673 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded and your steps (caption for a frame), but not problem to insert Fig. So no idea, why it doesn't work for you. If you like, you can reset your Libreoffice profile (https://wiki.documentfoundation.org/UserProfile) and re-test, to be certain the reported issue is not related to corruption in the user profile.
My machine has many accounts, so I tested under several user-ids. Some have different UI languages or default document languages. Same behaviour. The probability that all user profiles are damages is rather low. I tried another approach. Captions are related to number ranges. Therefore I created separately a number range with a dot and characters outside ASCII (accented letters). This was accepted. After that, I Insert>Caption. The category menu now contains the strange name and I can use it. Apparently, the mishap may be related to the UI. There may be constraints imposed on this GTK widget (I did not read the code), perhaps a different system configuration in Linux settings outside LO. I can consider this is an acceptable workaround: explicitly define a number range, so that a typo in the Category will not have unexpected consequences. But how can I handle the case where I want "Figure" and "Fig." applied to the same number range? The use case would be to keep a single line caption on moderately long title (a bit contorted because two letters won"t make a big difference). My request may not make sense but it is suggested by my discussion with OP on AskLO.
Can not reproduce with 6.2.8 on Windows, either. Following steps in comment #2, I can change the "Figure" category name to either "Fig." or "Décoration" just fine. (In reply to ajlittoz from comment #4) > Apparently, the mishap may be related to the UI. There may be constraints > imposed on this GTK widget (I did not read the code), perhaps a different > system configuration in Linux settings outside LO. It may be Linux or GTK specific. One way to test is forcing LO to stop using GTK VCL backend and user X11 instead, by setting the SAL_USE_VCLPLUGIN environment variable on command line, like: $ SAL_USE_VCLPLUGIN=gen libreoffice Would you please re-test with that?
(In reply to Ming Hua from comment #5) > Would you please re-test with that? => NEEDINFO
$ SAL_USE_VCLPLUGIN=gen soffice --writer opens Writer but all widgets are blank, no menu bar, no icons, style side pane is blank though I can select items in it. I think I didn't install all VCL plugins and Fedora uses Wayland, not X11. I'm midway of upgrading from Fedora 31 to Fedora 32. Will retry as soon as upgrade has completed, eventually installing other plugins. Will report then.
(In reply to ajlittoz from comment #7) > $ SAL_USE_VCLPLUGIN=gen soffice --writer > > opens Writer but all widgets are blank, no menu bar, no icons, style side > pane is blank though I can select items in it. > > I think I didn't install all VCL plugins and Fedora uses Wayland, not X11. Right. X11 VCL backend won't work if you don't have X11, obviously. > I'm midway of upgrading from Fedora 31 to Fedora 32. Will retry as soon as > upgrade has completed, eventually installing other plugins. Will report then. Thanks for testing. If getting X11 instead of Wayland is too much hassle on Fedora, you can also install the KDE VCL (called kf5, should be default if you start LO from KDE) and test that one.
While wauting for my desktop to upgrade, I made a test on my laptop with LO 4.1.6.2 (I know, very old release, but some important data on my laptop hasn't yet been converted; nothing to do LO though). Laptop is configured with X11. I can type exotic characters in the Cetgory field and the number range is automatically created. I checked with Inert>Cross-references. But if characters are typed on the numeric keypad, they are not accepted though the keypad is in NumLock mode. I asked the OP if he typed his dot on the keypad.
After upgrade: Version: 6.4.3.2 Build ID: 6.4.3.2-1.fc32 CPU threads: 4; OS: Linux 5.6; UI render: GL; VCL: gtk3_kde5; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded I explicitly installed libreoffice-kf5 because installation process defaults to gtk3 though I'm uner KDE Plasma. Same behaviour, but I observed that typing an "invalid" character (i.e. non ASCII letters, digits or underscores) repeats the last valid typed character! I.e., If I type "Abc" in Category, then a dot (whether main keyboard or numeric key pad), I get "Abcc" "c" being the last typed character. If you can't reproduce it and it works for others, never mind. My workaround of defining a number range before inserting the caption is acceptable for me. I don't know for OP on AskLO.
I know almost nothing about Fedora package names or using LO in KDE, but - (In reply to ajlittoz from comment #10) > Version: 6.4.3.2 > Build ID: 6.4.3.2-1.fc32 > CPU threads: 4; OS: Linux 5.6; UI render: GL; VCL: gtk3_kde5; This is not right. For kf5 VCL this should read "VCL: kf5" (see the many bugs blocking bug 102495), I have no idea what "gtk3_kde5" is supposed to be. > Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US > Calc: threaded > > I explicitly installed libreoffice-kf5 because installation process defaults > to gtk3 though I'm uner KDE Plasma. If you are still interested in testing you can search around and see how to enable kf5 VCL on Fedora.
I was quite surprised by the "gtk3_kde5". Before I installed the libreoffice-kf5 package, that field read "gtk3". I remember having had problems in the previous Fedora (or the one before) with these adaptation layers, notably with kf5. So, after your remarks, I checked twice the packages (can't use the GUI because it crashes with an error in the daemon "connection reset by peer"; command line is OK but not user-friendly). There is a libreoffice-kde5 which I installed. Now I have: Version: 6.4.3.2 Build ID: 6.4.3.2-1.fc32 CPU threads: 4; OS: Linux 5.6; UI render: GL; VCL: kf5; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded Puzzled, I removed libreoffice-kf5 (mainly because I did no install the KDE Framework(s)), but it still reads kf5 (though now only libreoffice-kde5 is present). I retested the sequence `Insert`>`Frame`, `Insert`>`Caption` and patching the Figure category to make it Fig. Working! And the corresponding number range is also created. It definitely appears to be a question of GUI interface. Thank you for pointing me in the right direction. I let you close this bug report because I think it should conclude with a caveat for developers responsible of the various desktop interfaces. And also a caveat for users to emphasize on the need to explicitly check which interface the installer chose to eventually correct an inconsistent choice.
(In reply to ajlittoz from comment #12) > Thank you for pointing me in the right direction. Thank you for testing! > I let you close this bug report because I think it should conclude with a > caveat for developers responsible of the various desktop interfaces. > > And also a caveat for users to emphasize on the need to explicitly check > which interface the installer chose to eventually correct an inconsistent > choice. If you don't mind, I'd like to leave this bug open since it's still a real problem for GTK users. I'll ping the GTK3 VCL meta bug and see if any developers there is interested in further investigation.
(In reply to Ming Hua from comment #13) > If you don't mind, I'd like to leave this bug open since it's still a real > problem for GTK users. I'll ping the GTK3 VCL meta bug and see if any > developers there is interested in further investigation. You're the wise guy; I'm no developer. I just thought of avoiding keeping unclosed bugs in the database. I agree with you this is some kind of bug. Additional information: This bug does not occur on my laptop nor in previous configurations of my desktop because several desktop managers are installed (KDE and GNOME) because of specific applications. I changed my mind on my mind on my desktop recently and began to reconfigure it with only KDE, very strict firewall rules and SELinux policy and minimal number of packages. This means only the strictly necessary packages are brought by dependency resolution. There may also be a Fedora packaging issue. By default Fedora installs GNOME and AFAIK there is no automatic sensiing for the installed desktops (how could they know beyond the active one). Consequently, when an application has several desktop (or widget) interfaces, only the "distro default" is installed. I guess many libraries are missing because of my choice and widget handling reverts to some fallback strategy. It usually does not matter but this seems to be a corner case.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/50ed0fd8a51c465589da21b1414e2c2e239e986a Resolves: tdf#132626 entry_insert_text works on the newly typed region It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed in master, backport to 6-4 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/bc64f99a6a6a2134bd63d47dbfa23ed1d6cfd754 Resolves: tdf#132626 entry_insert_text works on the newly typed region It will be available in 6.4.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.