Description: In a document with: - some text formatted with Strong Emphasis Character Style - some text formatted with Bold (Direct Formatting) - and some other text with Strong Emphasis Character Style + Bold (Direct Formatting) when using Find & Replace to search for Bold formatting, all texts with Bold direct formatting are found (ok). However, when checking the Including Style option, only the texts with only one of the formatting are found (Strong Emphasis Character Style OR Bold (Direct Formatting), but not the text with both formatting). The text with both Strong Emphasis Character Style formatting and Bold (Direct Formatting) is not found contrary to what one would expect. Steps to Reproduce: 1. Edit a text with the three formatting combinations described above: a) Strong Emphasis Character Style, b) Bold (Direct Formatting), c) both Strong Emphasis Character Style + Bold (Direct Formatting) 2. Open Find & Replace and search for bold formatted text, with or without the Including Style option checked Actual Results: With Including Style checked, the text with both formatting is not found. Expected Results: Checking the Including Style option should find all three combinations of formatting. Reproducible: Always User Profile Reset: No Additional Info:
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Looks like a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=128064
Created attachment 155478 [details] Demo file with all three combinations of formatting. Thank you for the reply. Please find here attached a sample file.
[Automated Action] NeedInfo-To-Unconfirmed
Already seen in 3.3.0. Note that you should never mix direct formatting and styles in practice. Arch Linux 64-bit Version: 7.0.0.0.alpha0+ Build ID: 6a9c7409ee617b79c327dd7ea4de432f448b6006 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 24 April 2020
(In reply to Buovjaga from comment #5) > Already seen in 3.3.0. > > Note that you should never mix direct formatting and styles in practice. > How to do it?, at least Default it's always there.
(In reply to m.a.riosv from comment #6) > (In reply to Buovjaga from comment #5) > > Already seen in 3.3.0. > > > > Note that you should never mix direct formatting and styles in practice. > > > How to do it?, at least Default it's always there. Default doesn't seem to have any problems with Find & replace & formatted text.
Dear Alex, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
repro Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 98f0dd5e15733ac7f1d929d06ab230b5f04121d5 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded Here is another variation on the problem. 1. Make two copies of: "Here is a sentence in all bold" 2. Apply DF bold to both copies, then apply "Strong Emphasis" CS to the word "sentence" 3. Critical step: In the second sentence, put the cursor immediately after "sentence" and press Ctrl-M (clear direct formating) 4. Find&Replace with "Bold" format, and with and without "Including styles" option Actual: If "including styles" is selected, then only beginning of Sentence 1 (up to CS) is found. Expected: That CS is found in sentence 1, and part after CS is also found. Actual: If "including styles" is not selected, then Sentence 2 is not found. Expected: That non-CS parts of sentence 2 are found when not using "including styles". Using Style Inspector is helpful. Problems seem to arise both for (a) strings that have both DF character and CS char weights, and (b) DF paragraph and CS char weights.