Bug 159533 - Add custom separators to all field variables
Summary: Add custom separators to all field variables
Status: RESOLVED WONTFIX
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: https://ask.libreoffice.org/t/separat...
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Fields-Variable
  Show dependency treegraph
 
Reported: 2024-02-02 19:38 UTC by William Friedman
Modified: 2024-03-15 10:50 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (11.80 KB, application/vnd.oasis.opendocument.text)
2024-03-14 09:52 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description William Friedman 2024-02-02 19:38:28 UTC
Description:
I am requesting the ability to add a custom separator to the insertion of field variables. Here is my use case. I write in my text: "There are ten examples: 1) blah, 2) blah blah, 3) blah blah blah" etc. Each of the numbers is the field variable, but I have to manually enter the parentheses as the separator. I would like to be able to set up the field variable to have a separator, just like one can do with ordinary lists (but since multiple list entries can't go on a single line, number range fields must be used instead). The current option to insert a separator "with heading number" does not do what I want. Ideally the separator could be configurable to allow an arbitrary number of characters *before and after* the number, so that one could automatically insert, e.g. [1]). Thank you for considering this enhancement.

Steps to Reproduce:
1. Go to Fields | Variables.
2. See that there is no option for adding a separator.

Actual Results:
No option for adding a separator.

Expected Results:
Option for adding a separator.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 1 Heiko Tietze 2024-03-08 10:25:44 UTC
Please elaborate on the use case. Why do you need "There are ten examples: 1) blah..." to appear as a field, and not a hyperlink for example?

If this should be a list why not use a cross-reference using 'Number (no context)'?

And if the source is like "Chapter 1: Heading" and you want "example: in 1) lorem" I wonder if this is a common way to do cross-referencing, ie. requested by some standard, or a nice use case.
Comment 2 William Friedman 2024-03-08 15:00:50 UTC
The use case is for an in-line list. The fields are not cross-references, just numbers enumerating the elements of the list, just like in ordinary lists. Since one can customize the separator for regular lists, the enhancement request is to add the possibility of using separators for field variables as well, since there is no other way of making an in-line list.
Comment 3 Heiko Tietze 2024-03-11 14:39:11 UTC
The use case is still weak. Why is the inline list sorted, and how do you access the items later.

Basically we are bound to the standardized document format. And fields just do not have a separator attribute that could be read by alternative office programs. Using some macro is of course always an option, in particular since you probably want to use a shortcut for the list item field.
Comment 4 William Friedman 2024-03-12 14:52:15 UTC
The use case, as I said, is to try to implement in-line lists. I admit it's a kludge, but until the normal list function allows for in-line lists, the only way to create an in-line list is to use variables.

I'm not sure what's unclear about the use case. They are the same use cases as ordinary lists. Here's an example of how one might use this:

Issue X is discussed in [*3*] sources: *1*) A, *2*) B, *3*) C. According to source [*1*], blah; according to source [*2*], blah blah. According to source [*3*], however, ...

In this example, *1*, *2*, and *3* are the field variables. The content of the square brackets are references to those variables. The first one refers to the largest numbered variable, and the next three refer to the individual variables of the list.

What I'm asking for, specifically, is the ability to customize the separator surrounding each of those variables -- the close parenthesis in this example -- just like I can customize the separator after ordinary list numbers in Bullets and Numbering | Customize | Separator. Again, this wouldn't be necessary if Lists & Numbering supported in-line lists, but it doesn't. This also wouldn't be necessary if one could search and replace field variables, but that also isn't a possibility.
Comment 5 Heiko Tietze 2024-03-13 07:35:11 UTC
Mike, what do you think?
Comment 6 Mike Kaganski 2024-03-13 07:39:14 UTC
(In reply to Heiko Tietze from comment #5)
> Mike, what do you think?

There is already an implementation of "inline lists", which IIRC Michael Stahl had implemented for Word compatibility; it is implemented by marking the "paragraph mark" as hidden. It has no UI for now, as well as other "paragraph mark" properties; and IMO, the proper thing would be to implement the UI. I remember that there was some "missing UI for paragraph mark" bug report (or maybe some mention in another bug) ...
Comment 7 Michael Stahl (allotropia) 2024-03-13 10:08:33 UTC
(In reply to Mike Kaganski from comment #6)
> There is already an implementation of "inline lists", which IIRC Michael
> Stahl had implemented for Word compatibility; it is implemented by marking
> the "paragraph mark" as hidden. It has no UI for now, as well as other
> "paragraph mark" properties; and IMO, the proper thing would be to implement
> the UI. I remember that there was some "missing UI for paragraph mark" bug
> report (or maybe some mention in another bug) ...

yes the UI for this is missing, forgot if there is a bug for it...

you want to create "inline lists" by hiding paragraph marks?
...
i have just tried this in Word and am happy to report that it doesn't work,
you get only the first paragraph's list number  :)
Comment 8 Mike Kaganski 2024-03-13 10:14:45 UTC
Thanks Michael; then please ignore me - since the mentioned feature isn't appropriate for inline list creation, then no objections to have some "before"/"after" affixes for number range fields, similar to what lists have.
Comment 9 Heiko Tietze 2024-03-14 09:52:04 UTC
Created attachment 193110 [details]
Example file

Checked the function and it works out of the box. You need to set a self-referencing variable and define an "Additional (number) formats..." where the number is followed by the parenthesis, like "0)".

But I have no idea how you would add a cross-reference to a specific item in this SEQ-list. And you also don't know the total number before the sequence starts, only afterwards.

(In reply to William Friedman from comment #4)
> Issue X is discussed in [*3*] sources: *1*) A, *2*) B, *3*) C. According to source [*1*]
See the attached document.
Comment 10 William Friedman 2024-03-14 18:42:46 UTC
Thank you, Heiko. The reason I didn't see this feature is because Fields | Variables | Number Range | Format doesn't allow a user-defined format, whereas Set Variable does (and, when incremented in this way, basically reproduce Number Range). Is there a reason not to allow user-defined formats for Number Range?

The limitations you point out -- no apparent way to reference an individual element, no way to display the total number of elements -- are severe. Is there any reason not to file an enhancement request to fix them?
Comment 11 Heiko Tietze 2024-03-15 10:50:11 UTC
(In reply to William Friedman from comment #10)
> Fields | Variables | Number Range | Format
And how do you cross-reference this field?

> Is there any reason not to file an enhancement request to fix them?
You are getting me onboard - but still no cigar :-)

Seriously, you define a use case that needs to be solved, not a solution that we have to implement. UX should verify the use case, ensure it's generic, without impact on other workflows, and eventually suggesting the UI/UX part of implementation.

Technically we are limited by the format. ODF 1.2 defines

7.4.13 <text:sequence>
The <text:sequence> element has the following attributes: style:num-format

19.500 style:num-format
The values of the style:num-format attribute are 1, i, I, a value of type string 18.2, an empty string, a or A.

19.503 style:num-suffix
The style:num-prefix and style:num-suffix attributes specify what to display before and after the number.

I read this as if we can access the style:num-format in a text:sequence but not the style:num-suffix. It requires a change to the file format (that needs to be implemented in all applications - and all other formats too).