Download it now!
Bug 132626 - CAPTION DIALOG: Can't type dot in caption category [STR in comment 2, GTK3 VCL only]
Summary: CAPTION DIALOG: Can't type dot in caption category [STR in comment 2, GTK3 VC...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.5.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.0.0 target:6.4.5
Keywords:
Depends on:
Blocks: GTK3 Caption
  Show dependency treegraph
 
Reported: 2020-05-03 08:43 UTC by ajlittoz
Modified: 2020-05-19 19:09 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ajlittoz 2020-05-03 08:43:26 UTC
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.
Comment 1 Dieter 2020-05-07 11:59:03 UTC
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.
Comment 2 ajlittoz 2020-05-08 08:57:10 UTC
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?
Comment 3 Dieter 2020-05-08 09:11:00 UTC
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.
Comment 4 ajlittoz 2020-05-08 10:04:50 UTC
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.
Comment 5 Ming Hua 2020-05-08 11:28:29 UTC
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?
Comment 6 Dieter 2020-05-08 11:31:03 UTC
(In reply to Ming Hua from comment #5)
> Would you please re-test with that?

=> NEEDINFO
Comment 7 ajlittoz 2020-05-08 14:08:44 UTC
$ 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.
Comment 8 Ming Hua 2020-05-08 14:26:43 UTC
(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.
Comment 9 ajlittoz 2020-05-08 14:39:30 UTC
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.
Comment 10 ajlittoz 2020-05-08 16:50:35 UTC
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.
Comment 11 Ming Hua 2020-05-08 17:02:49 UTC
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.
Comment 12 ajlittoz 2020-05-08 18:52:23 UTC
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.
Comment 13 Ming Hua 2020-05-09 01:02:57 UTC
(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.
Comment 14 ajlittoz 2020-05-09 08:01:16 UTC
(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.
Comment 15 Commit Notification 2020-05-10 20:11:11 UTC
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.
Comment 16 Caolán McNamara 2020-05-10 20:21:28 UTC
fixed in master, backport to 6-4 in gerrit
Comment 17 Commit Notification 2020-05-11 07:30:48 UTC
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.