Bug 159002 - It should be possible to insert a TAB character before caption text when using "AutoCaption"
Summary: It should be possible to insert a TAB character before caption text when usin...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.6.4.1 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: AutoCaption
  Show dependency treegraph
 
Reported: 2024-01-03 19:11 UTC by leceicer
Modified: 2024-01-15 11:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Clarification pictures (252.75 KB, image/png)
2024-01-03 19:22 UTC, leceicer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description leceicer 2024-01-03 19:11:15 UTC
Description:
It should be possible to insert a TAB character "Before caption" when using "AutoCaption".
See attached picture Fig 11.

I would very much appreciate not to have to use a macro as described below.

Steps to Reproduce:
Enhancement request.

Actual Results:
Enhancement request.

Expected Results:
See Fig 11, Fig 12, Fig 13.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: sv-SE (en_SE); UI: en-GB
Calc: CL threaded


***** Here follows some background information *****
"Insert Image" as an example.
I want the caption to look like this:

Bild xx:[tab character]Text describing the image. .........
                        ....................................
                        ....................................

See attached Fig 23.

I now solve this by a macro searching for the string "%%£ Auto Replace £%%" (seen in tha attached Fig 12) and replacing it by a TAB character.

The macro is triggered by "Click object" for the autoinserted "Frame".
The system thinks the "Frame" is clicked when inserting it. I dont have to click the Frame.

By using suitable values for tab stop and indentation in the Caption Style (in this case "Bild") the caption lines up for captions of several text rows.
***** End of background information *****
Comment 1 leceicer 2024-01-03 19:22:56 UTC
Created attachment 191734 [details]
Clarification pictures
Comment 2 leceicer 2024-01-03 19:27:49 UTC
Please replace all references to Fig xx with references to Fig 11.
Sorry for the mess!
Comment 3 Dieter 2024-01-14 20:49:20 UTC
Thank you for your suggestion. Let's ask design-team

Steps:
1. Tools -> Options -> LibreOffice Writer -> AutoCaption

Actual result:
Not possible to select "Tab stop" at "Before Caption" as additional option
Comment 4 Heiko Tietze 2024-01-15 10:45:49 UTC
Whether Auto- or just (Insert) Caption, the function produces a paragraph inside a frame and you can change the paragraph attributes. If you do so for the "Figure" style, ie. indent +2 / first line -2, some spacing will be added. It will not become some kind of block mode. While testing this it appears that the image itself is anchored As Character and thereby becomes indented too. Could be solved by changing the anchor to To Paragraph.

Would be nice being able to tweak the association between the type Illustration and what style is used. However not crucial.

The idea with regular expressions in position data might be tempting but is quite nerdy. Only experts would know about /t or /n - and should better solve the problem with a macro (or insert the tab manually). => WF

In the end I wonder what scenario requires this layout. Is there any official style that demands it?
Comment 5 Mike Kaganski 2024-01-15 11:08:04 UTC
(In reply to Heiko Tietze from comment #4)
> The idea with regular expressions in position data

Let me make a note first, about terminology. Regular expression is *a mask, against which some other text is matched according to rules*. As such, "regular expression" term is *only* applicable in search context. Here it is *not applicable*. Let us call the possible "\t", "\n" syntax simply "meta-characters". (See also: tdf#153212.)

> might be tempting but is quite nerdy. Only experts would know about /t or /n

No. I would support introduction of meta-characters support here; and it would be quite wise to do two things:

1. Make sure to use the same meta-characters as in Replace box of Find & Replace dialog (when searching with regular expressions); this condition would also benefit automatically from a potential fixes like "allow Unicode meta-characters in replace box" (tdf#106137).

2. Add a checkbox in the Insert Caption dialog, which would enable meta-characters. This would make it easily discoverable; tooltips could provide more frequent samples, and of course, updated Help would contain the information.


> and should better solve the problem with a macro (or insert the tab manually).

Oh, I disagree. People already have the Insert Caption dialog simply *to automatize a sequence of the following simple actions*:

1. Put the object into a frame (select the object -> Insert -> Frame);
2. Add a text after (or before) the object;
3. Insert a number range field;
... some more actions. Of course, they may all be implemented using macros... let's remove the function! (And the whole Writer altogether - we may generate ODF directly from Python.)

Seriously: this is about "some characters, that one might legitimately want to see in a caption, can't be inserted using the existing dialog. Let's fix this shortcoming". I do not see a real problem in doing this.
Comment 6 Heiko Tietze 2024-01-15 11:16:51 UTC
If aware of the feature, I'd expect the meta character to be in all dialogs where before/after attributes are possible. In particular Bullets & Numbering.

(In reply to Mike Kaganski from comment #5)
> 2. Add a checkbox in the Insert Caption dialog, which would enable
> meta-characters. This would make it easily discoverable; tooltips could
> provide more frequent samples, and of course, updated Help would contain the
> information.
Would be too heavy (and useless) IMO. If this is implemented it should be an expert function, kind of hidden (of course users can read the help to find out).

Nothing to say against such addition from the UX side (although I still struggle with the need).