Created attachment 205985 [details] PDF export You can export emoji from LibreOffice Impress. I use emoji: ❌ and ✔️ Steps to reproduce: 1. Create new Presentation with Impress 2. Copy Paste emoji "❌ and ✔️" 3. Save and export as PDF
Tested with the emojis shown in this report. Could see the emojis also in exported *.pdf So I couldn't reproduce the buggy behavior. Version: 26.2.1.2 (X86_64) Build ID: 8399f6259d8c87f40e7255cdb3c9b958f5e08948 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Better add an Impress example than the exported *.pdf-file. Might be it happens special with the font you have used. It is NotoColorEmoji and the properties show this font as "True Type" in the pdf. When exporting here on OpenSUSE 15.6 the font is shown as "Typ 3" and it could be seen on screen.
Created attachment 205991 [details] Impress file
Same behavior with attached Impress file: Could see the emojis in Impress and also in exported pdf file. NotoColorEmoji is shown here as "Type 3" and not as "True Type", as it is shown in the first attachment "Emoji.pdf"
Created attachment 205993 [details] Exported PDF file from original Impress file - have a look at embedded fonts.
So what's the problem. I just noticed that I have old file with emoji that render just fine. Copy paste the same emoji into the new file and they are not rendered.
No repro with Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 56f2abbf3f107d849305df507818f00e6f6086df CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
(In reply to Jakub T. Jankiewicz from comment #5) > So what's the problem. I just noticed that I have old file with emoji that > render just fine. Copy paste the same emoji into the new file and they are > not rendered. I would reset the user profile of LO. The font type isn't detected the right way for the special emoji-font you use. Also changing the font type would help.
from the meta.xml of sample doc attachment 205991 [details] <meta:generator>LibreOffice/25.8.5.2$Linux_X86_64 LibreOffice_project/580$Build-2</meta:generator></office:meta> So this was a Linux fontconfig fallback issue. Assignment of NotoColorEmoji font for the Emoji that are not present in OpenSymbol or Liberation Serif that the template uses for sd objects. Slightly different on Windows builds, where rather than the Segoe UI Emoji that contains the U+274C and U+2714 with U+FE0F VS16. The export to PDF uses fall back to OpenSymbol. But IFF I explicitly assign DF of the Emoji to use SegoeUI Emoji for the glyphs, no fall back occurs and the PDF is exported with correct subset SegoeUI Emoji font and renders in PDF viewers. Needinfo to OP, if you explicitly set the DF of the emoji's inserted to canvas to use as in your case Noto Color Emoji--does that removal of the fontconfig fallback then clean up your exported PDF? Also, watch out for any export as PDF form--filter expected to behave differently there for fielded content.
So I set the font to Noto Emoji for a single glyph and the whole text field. I also reset everything to factory settings. Nothing changed. I still don't have emojis in the generated PDF file.
(In reply to Jakub T. Jankiewicz from comment #9) > So I set the font to Noto Emoji for a single glyph and the whole text field. > I also reset everything to factory settings. Nothing changed. > > I still don't have emojis in the generated PDF file. You are using LO, which is packed by your Linux-distribution? Try a parallel installed version downloaded from LO. https://wiki.documentfoundation.org/Installing_in_parallel
Yes, I'm using the official repo from Fedora. Installed parallel version. Still the same issue.
Created attachment 206030 [details] Impress file from parallel installation
The file from parallel install is ~20MB.
Actually thinking about this recalled bug 151057 and our lack of support for the COLR table. Downloaded current Noto Color Emoji and installed to Windows. Made specific font assignments for string: U+274c and U+2714U+fe0f then converted with Alt+X In fact the Noto Color Emoji (shows as COLRv1) does not render a glyph to document canvas, nor does it export to PDF. Seems this is Windows specific mishandling of the Noto Color Emoji The Noto Emoji are fine, as are the Segoe UI flavors (Segoe UI Emoji is a COLRv0). So believe this a dup of bug 151057 *** This bug has been marked as a duplicate of bug 151057 ***
Created attachment 206044 [details] sample of emoji fonts on Writer canvas, the Noto Color Emoji (a COLRv1 font) is not rendered, nor exported The COLRv0 fonts render and export since 7.5.0 as for bug 104403
Note: I have a different presentation with emoji and a PDF that shows them. The file and PDF were created in August 2025, also on Fedora. https://commons.wikimedia.org/w/index.php?title=File%3APrezentacja_z_Commons_i_Prawa_Autorskiego_v2.pdf&page=40 Emojis are on the last slide. When I tried to export again, no emoji. But a year ago I had Fedora upgraded from around version 30. I failed to upgrade last year and installed a fresh system. I'm not sure about the differences. I don't recall doing anything specific about emojis.
A quick search suggests Fedora 42 and earlier used the COLRv0 flavor of Noto Color Emoji; from Fedora 43 onward they changed to the COLRv1 versions.
Earlier versions of Noto Color Emoji used bitmap (CBDT) color glyphs, and we support this. New versions use vector (COLR v1) color glyphs, which we don‘t support yet (as explained in comment 14). Your Fefora upgrade likely upgraded also the font. As a workaround, you can install the NotoColorEmoji.ttf file from https://github.com/googlefonts/noto-emoji/tree/main/fonts, which uses CBDT table.