Bug 140648 - Bullet dialogs convert non-opensymbol supported bullet symbols to U+FFFD, can't use things like emojis (Noto Color Emoji font for example)
Summary: Bullet dialogs convert non-opensymbol supported bullet symbols to U+FFFD, can...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-24 19:40 UTC by Peter Gervai
Modified: 2021-09-13 06:34 UTC (History)
1 user (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 Peter Gervai 2021-02-24 19:40:28 UTC
Description:
Can't use a character for bullet despite matching Character, Numbering and Paragraph styles. 

May be vaguely related to already many years old issues like bug#77743  or bug#112019 


Steps to Reproduce:
1. Create a Character Style for Emoji (Noto Color Emoji font, for example)
2. Create a Numbering Style for Emoji bullets using #1 Char Style, select character using the Emoji font and search (example was: "run" - running man)
3. Create a Paragraph style using #2 Num Style.
4. Try to apply it and see failing.


Actual Results:
Even at step 2 you will see that the glyph gets converted to Unknown Glyph (U+FFFD). This is the same you'll see at the end. 
While the bullets seem to use random/default font (in the final doc) it does not matter: manually hacking it into the Noto Emoji shows U+FFFD either.

Expected Results:
Showing the actual character in the actual chosen character set as bullets.



Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: hu-HU (hu_HU.UTF8); UI: en-US
Debian package version: 1:7.0.4_rc2-1+b1
Calc: threaded
Comment 1 Dieter 2021-09-12 08:40:03 UTC
Peter, unfortunately nobody could confirm this bug report for half a year. So I'd like to ask, if it is still valid. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 2 Peter Gervai 2021-09-13 06:34:16 UTC
@Dieter: interestingly it works now (now being v7.1.1.2_rc2), and it have not worked then. Let us rejoice that someone have fixed something unicode related somewhere and it automagically have fixed this, too!

Thanks!