Bug 153903 - "Category and Number" and "Caption Text" in Cross-reference variable dialog are limited to fixed structural relations (see c4,c5,c8)
Summary: "Category and Number" and "Caption Text" in Cross-reference variable dialog ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.6.0
Keywords:
Depends on:
Blocks: Fields-Cross-Reference
  Show dependency treegraph
 
Reported: 2023-03-01 16:25 UTC by sdc.blanco
Modified: 2023-04-14 03:19 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
demonstration of problem with Category and Number and Caption Text (15.22 KB, application/vnd.oasis.opendocument.text)
2023-03-01 16:25 UTC, sdc.blanco
Details
screenshot of current Cross-reference dialog for number range variables (21.53 KB, image/png)
2023-03-16 11:54 UTC, sdc.blanco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2023-03-01 16:25:11 UTC
Created attachment 185671 [details]
demonstration of problem with Category and Number and Caption Text

The topic is the cross-reference dialog (Ctrl-F2), cross-references tab.

The problem concerns the "Category and Number" and "Caption Text" options in the "Refer to" window.

The attached document demonstrates that these two options depend on/presuppose the caption structure:

[Category Name] [Caption Number] [Caption Text].

Captions with this structure will behave as "expected" when using this dialog.

Deviations from this structure (as illustrated in the attachment) will not give "expected" behavior.

Although the attachment may be considered a pathological case, there are actual cases where formatting is:   Caption Text  ([Category Name] [Caption Number])
With that structure, then cross-references to "Caption Text" would not work as expected. 

NB. The example in the attachment uses "Table", but the same point can be illustrated any number range variable.

(tested with 7.2.7.2 and 7.6.0.0.alpha0+)
Comment 1 sdc.blanco 2023-03-01 16:39:20 UTC
OP only describes problematic situation. 
Matter of taste whether this is bug or enhancement request.

Obviously, expected behavior is that "Category and Number" show only Category Number and "Caption Text" shows only caption text.

Solution is more difficult because, at present, there is no systematic way to identify (markup) these three components in the caption label. 

Solution to this bug would probably also provide a solution to bug 148597, and may be relevant to bug 114467.
Comment 2 Eyal Rozenberg 2023-03-12 20:13:10 UTC
I'd say it's a bug to be fixed.
Comment 3 sdc.blanco 2023-03-15 00:22:35 UTC Comment hidden (off-topic)
Comment 4 Heiko Tietze 2023-03-15 10:18:47 UTC
The issue is that, for example
a) Figure 1: Lorem ipsum  = CC C#: CT
b) Lorem ipsum (Figure 1) = CT (CC C#)

the cross-reference of a) for caption text is correct while b) would be empty. Obviously the program treats everything _after_ the caption number as text.

If we follow André's suggestion from bug 148597 comment 20, discussed in bug 153248 the CT field would have a clear definition. Until then I suggest to just treat everything which is not category or number as text. Meaning "Lorem Figure 1: ipsum" generates "Lorem ipsum" as cross-reference.

(Ignoring the other topics in c3.)
Comment 5 sdc.blanco 2023-03-15 19:16:59 UTC
(In reply to Heiko Tietze from comment #4)
> Until then I suggest to just treat everything which is not category 
> or number as text.
iiuc, this is a proposal for changing the current implementation (until a better solution, e.g., a CT field) is developed?

Perhaps an EasyHack?  I am guessing the change would be needed around here: https://opengrok.libreoffice.org/xref/core/sw/source/core/fields/reffld.cxx?r=71337b43#558

Such a hack would also have to address the current behavior that any text between the category name and caption number is currently included when the "Category and Number" option is chosen. In relation to the proposal, perhaps that text should not be included as "Caption Text"?

If not an EasyHack, then maybe better to wait for a CT field?
Comment 6 Heiko Tietze 2023-03-16 09:37:05 UTC
I would not wait for a CT-tag solution. Don't see a clear path to implement it, so not really easyhackable. Maybe Andreas is interested.
Comment 7 sdc.blanco 2023-03-16 10:36:52 UTC
@Heiko -- need to ask again.  

1. It is clear that CT is not likely happen in the near future (as a better solution to this and other tickets).

2. In light of that, Comment 3 suggests an "improvement" to the help page, so that it describes accurately the actual behavior of the cross-reference variables -- without having to tell about the "inelegancy" that motivated this ticket. This would, at least, provide the information needed to understand/explain (possible unexpected) behavior of the cross-reference choices (with no need for implementation changes).

3. Your response (comment 4) to that improvement suggestion seems to indicate (as a temporary improvement) "to just treat everything which is not category or number as text".

My queries remain:  

1. Should that comment 4 suggestion become the summary of this ticket?
2. Is that suggestion an EasyHack? If not, then maybe not worth making?
3. I can update the help page (using the descriptions in comment 3), but if an EasyHack was going to change the current behavior, then I would wait with the updating.
Comment 8 Heiko Tietze 2023-03-16 10:46:49 UTC
(In reply to sdc.blanco from comment #7)
> 1. Should that comment 4 suggestion become the summary of this ticket?
The summary describes the issue precisely. Any other solution than my proposed is welcome.

> 2. Is that suggestion an EasyHack? If not, then maybe not worth making?
I don't know if it's easy to hack. But the issue is clear and definitely worth to realize (as long it does not mean S/M-size or smaller).

> 3. I can update the help page (using the descriptions in comment 3)...
Wouldn't do so unless something has been implemented. You may add a note for now but maybe tomorrow someone provides a patch...
Comment 9 sdc.blanco 2023-03-16 11:54:46 UTC Comment hidden (off-topic)
Comment 10 Commit Notification 2023-04-12 11:21:01 UTC Comment hidden (off-topic)
Comment 11 Commit Notification 2023-04-14 03:19:04 UTC Comment hidden (off-topic)