Bug 90385 - Some characters no longer display in Find & Replace
Summary: Some characters no longer display in Find & Replace
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Find-Search
  Show dependency treegraph
 
Reported: 2015-04-01 04:13 UTC by Matthew Francis
Modified: 2022-02-10 12:01 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document (8.50 KB, application/vnd.oasis.opendocument.text)
2015-04-01 04:15 UTC, Matthew Francis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2015-04-01 04:13:34 UTC
Split from bug 83754 

Since 4.4, "♦︎" (BLACK DIAMOND SUIT, U+2666 U+FE0E) does not display correctly in the Find & Replace Dialog on Linux

Steps to reproduce:
- Open the attached document
- Select the "♦︎"
- Open "Find & Replace" (Ctrl+H)

Expected result:
- Diamond displays in the search box

Actual result:
- Missing character square displays


This is probably a related phenomenon to bug 86399, but began occurring at a different point in history
Comment 1 Matthew Francis 2015-04-01 04:15:55 UTC
Created attachment 114513 [details]
Sample document
Comment 2 Matthew Francis 2015-04-01 04:19:16 UTC
Taking the liberty of setting this to NEW myself, as a commit has been identified.

This seems to have begun at the below commit.
Adding Cc: to matus@libreoffice.org; Could you possibly take a look at this? Thanks

(note also bug 86399, which had a similar effect on some other characters, but was caused by a different commit)


commit a6b00d16eb27a5e7e31c721671001a909ecef960
Author: Matúš Kukan <matus.kukan@collabora.com>
Date:   Tue May 27 16:37:30 2014 +0200

    Related bnc#822625: Cache FontEntry with the original FontSelectPattern.
    
    Otherwise we never hit cache directly, only after expensive call to
    ImplFindByFont.
    
    Change-Id: If15b368feeba94c8fff8ee7cbe049fc4a2069768
Comment 3 Matthew Francis 2015-04-02 13:42:03 UTC
(I was led up the garden path by a character picker in comment 0, the "U+FE0E", which is a modifier, is unnecessary to produce the character in question)
Comment 4 Matúš Kukan 2015-04-09 18:43:02 UTC
I was not able to reproduce this bug.
Perhaps, it was fixed too with b1030f75d3e47719ca63ec518f1da75196bead1a ? or is it something else?
Comment 5 Matthew Francis 2015-04-10 03:32:07 UTC
I can still reproduce this on Linux (Ubuntu 14.04) after b1030f75d3e47719ca63ec518f1da75196bead1a.
(Caolan's commit appears to deal with compound characters, which this isn't)

This one works on the same machine prior to the commit mentioned in comment 2, so it shouldn't be e.g. a matter of missing fonts.
Comment 6 Robinson Tryon (qubit) 2015-12-13 11:12:22 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2017-10-23 14:01:46 UTC Comment hidden (obsolete)
Comment 8 Timur 2019-11-29 19:36:05 UTC
I don't reproduce in Windows in 4.2 so not in 6.5+.
Comment 9 QA Administrators 2021-11-29 04:35:58 UTC Comment hidden (obsolete, spam)
Comment 10 Justin L 2022-02-10 12:01:27 UTC
There has been no confirmation activity on this bug report for 7 years. I tested on Ubuntu 16.04 with bibisect-linux-44max and 50max and couldn't reproduce. I can't reproduce on Ubuntu 20.04 with master either.

Marking as worksforme.