Bug 156988 - Find cannot find superscripted or subscripted text
Summary: Find cannot find superscripted or subscripted text
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:24.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-29 17:41 UTC by William Friedman
Modified: 2023-11-05 13:49 UTC (History)
5 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 William Friedman 2023-08-29 17:41:02 UTC
Description:
If the Find field is set to Format | Position | Superscript or Subscript, characters that are superscripted or subscripted are still not found. Note that setting Attributes | Position doesn't help. If *only* Attributes | Position is set, then all superscripted *and* subscripted text is found. But if Position *and* Format | Position | Superscript is set, superscripted text is not found.

Steps to Reproduce:
1. Open a new document.
2. Type a character (let's say "a", without the quotation marks).
3. Set that character to superscript.
4. Open the Find dialog (Ctrl-H).
5. Make sure the Find field is set to No Format.
6. Go to Format | Position, select Superscript, and hit OK.
7. In the Find field, type the character you typed (in our example, "a", without the quotation marks).
8. Hit Find All, Find Next, or Find Previous. See that "search key not found" appears.
9. In the Find field, type a period (".", without the quotation marks).
10. Enable regular expressions.
11. Hit Find All, Find Next, or Find Previous; they also say "search key not found."

Actual Results:
"Search key not found."

Expected Results:
The superscripted or subscripted text matching the search string should appear.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
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 Dieter 2023-09-16 11:19:05 UTC
William, thank you for reporting the bug. Could you please retest in SafeMode (Help -> Restart in SafeMode)? Thank you
=> NEEDINFO
Comment 2 William Friedman 2023-09-18 16:06:09 UTC
The same thing happens in SafeMode.
Comment 3 Stéphane Guillou (stragu) 2023-09-29 23:36:34 UTC
Tested in:

Version: 7.5.7.1 (X86_64) / LibreOffice Community
Build ID: 47eb0cf7efbacdee9b19ae25d6752381ede23126
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

If I search for the superscript format raised by 33% (the default), it won't match it. But if you tick "Automatic" next to "raise/lower by", it should match it.
Same with the "." regex.

Can you confirm that that works?
Comment 4 William Friedman 2023-10-02 14:59:43 UTC
Confirmed, ticking the automatic box on Search For Formatting | Position works, with both the letter and the regex.

This remains a bug, however, because automatic is not ticked by default, neither when super/subscripting nor when searching for super/subscripted text. 

(Also, I have no idea how automatic works, and the help is no help at all: "Automatically sets the amount by which the selected text is raised or lowered in relation to the baseline." Automatically based on what? And how is that different than the default "manual" percentage of 33%?)
Comment 5 Buovjaga 2023-10-25 11:05:55 UTC
(In reply to William Friedman from comment #4)
> Confirmed, ticking the automatic box on Search For Formatting | Position
> works, with both the letter and the regex.
> 
> This remains a bug, however, because automatic is not ticked by default,
> neither when super/subscripting nor when searching for super/subscripted
> text. 
> 
> (Also, I have no idea how automatic works, and the help is no help at all:
> "Automatically sets the amount by which the selected text is raised or
> lowered in relation to the baseline." Automatically based on what? And how
> is that different than the default "manual" percentage of 33%?)

UX team: change to default proposed.
Comment 6 V Stuart Foote 2023-10-25 11:33:01 UTC
Yes, we need to adjust the Find & Replace 'Format' -> 'Search for Formatting...' dialog so the 'Position' group is set to 'Automatic' by default for the find.

Justin has corrected all the raise/lower superscript/subscript to automatically take a value from font metric (see also bug 80194) so the manual values or the old default of 33% super/ 8% sub now is the exception.

@Justin, any thoughts? Was there more to be done for both assigning and searching format of the super/sub positioning?
Comment 7 Heiko Tietze 2023-10-25 13:04:50 UTC
(In reply to V Stuart Foote from comment #6)
> Yes, we need to adjust the Find & Replace 'Format' -> 'Search for
> Formatting...' dialog so the 'Position' group is set to 'Automatic' by
> default for the find.
+1
Comment 8 Justin L 2023-10-25 16:59:27 UTC
For 24.2 I set the toolbar to default to automatic, with
related tdf#80194 SvxEscapementItem: set auto flag as default

So, I assume something similar is needed for the "Search for formatting" dialog.

(In reply to V Stuart Foote from comment #6)
> Justin has corrected all the raise/lower superscript/subscript to
> automatically take a value from font metric (see also bug 80194) so the
> manual values or the old default of 33% super/ 8% sub now is the exception.
I don't think that is quite correct. I only changed automatic to DISPLAY based on the font metric. So my 7.0 work shouldn't affect a format search. I suggest this was inherited from OOo.

But the main thing to be noticed is that AUTOMATIC is a unique setting that simply will never match any specified percentage. So even if it displays at 33%, a search for 33% could never find it. And the current response is the correct one. You SHOULD be able to search for only automatically set superscripts. And therefore the corresponding is also true, that an automatic superscript would never match a search for the "normal" 33% superscript.

The short response is "I agree that this ticket can be closed when "Search for format" defaults to automatic for 24.2. Otherwise it is acting as expected.

In terms of the meaning of "automatic", it is exactly that - the computer gets to decide how the superscript is shown (which is not a static percentage). See the release notes for 7.0 if you want more details.
Comment 9 Justin L 2023-10-26 20:53:56 UTC
proposed fix at https://gerrit.libreoffice.org/c/core/+/158514
Comment 10 Commit Notification 2023-10-27 00:39:01 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7ac066438f6d029fd0be2f0c72207805b0ca8153

tdf#156988 chardlg: default to AUTO escapement

It will be available in 24.2.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 11 Justin L 2023-10-27 13:48:08 UTC
Some notes about this bug report:
1.) tdf#80194's 24.2 change wouldn't have affected Writer very much - Writer already made sure that the toolbar defaulted to Auto (already in OOo 3.3). So it would just be the other apps' toolbars that were affected in 24.2.

Thus, it is not surprising that OP was creating automatic superscripts. Confirmed with bibisect-releases that everything reported here was true for OOo 3.3 as well.

2.) My patch only affects the FIRST time (while Writer is open) that the format dialog is entered. The settings in the dialog are remembered as context and restored on the next entry into the Format dialog.

3.) This is the same dialog used for Format - Character etc. However, in those cases there is always a context (either a style default, or direct formatting default of the underlying text), and the "Normal" non-escapement context always set the automatic checkbox.

In the first run of the "Find - Format" dialog there is no context, so it follows a different code path - which I fixed.


Writer is the only app that can "Find - Format". So perhaps it would be safe to backport this. (I don't know if there are any other no-context situations where this dialog might be used outside of Writer.)