Bug 129523 - Color Emojis are not exported to PDF
Summary: Color Emojis are not exported to PDF
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: high major
Assignee: Not Assigned
: 144982 (view as bug list)
Depends on: 105488 151057 104403 121327
Blocks: PDF-Export
  Show dependency treegraph
Reported: 2019-12-20 15:33 UTC by febrezo
Modified: 2024-06-28 12:34 UTC (History)
25 users (show)

See Also:
Crash report or crash signature:

ODP and exported PDF with Emoji One Color font embedded (4.43 MB, application/x-zip-compressed)
2020-01-04 04:23 UTC, V Stuart Foote
1 On LibreOffice.jpg (375.84 KB, image/jpeg)
2021-03-07 11:40 UTC, Alberto Salvia Novella
2 On PDF export.png (183.70 KB, image/png)
2021-03-07 11:41 UTC, Alberto Salvia Novella
3 On any other application.jpg (428.08 KB, image/jpeg)
2021-03-07 11:41 UTC, Alberto Salvia Novella
err.log (13.91 KB, text/plain)
2021-03-07 11:42 UTC, Alberto Salvia Novella
Buovjaga's /etc/fonts (23.83 KB, application/gzip)
2021-03-07 12:48 UTC, Buovjaga
Moon symbols + Noto Color Emoji doesn't render at all on PDF side (103.65 KB, image/png)
2022-06-05 05:22 UTC, Jambunathan K
Moon Symbols: Translate `Noto Color Emoji` to `Symbola` (146.16 KB, image/png)
2022-06-05 05:23 UTC, Jambunathan K
Moon Symbols renders well with `Symbola` (62.31 KB, image/png)
2022-06-05 05:25 UTC, Jambunathan K
Moon symbols: `fc-list` on my Debian Unstabe (as recent as June 1, 2022) (403.18 KB, text/plain)
2022-06-05 05:26 UTC, Jambunathan K
moon-phases.odt: With `Noto Color Emoji` font (17.07 KB, application/vnd.oasis.opendocument.text)
2022-06-05 05:30 UTC, Jambunathan K
moon-phases.pdf: `moon-phases.odt` exported to `PDF` with `Noto Color Emoji` font (44.55 KB, application/pdf)
2022-06-05 05:38 UTC, Jambunathan K
Moon symbols: Rendered with Noto Emoji SVG; (64.10 KB, image/png)
2022-06-05 07:00 UTC, Jambunathan K
Font_EmojiOne_Color_1.ttf (5.91 MB, application/octet-stream)
2022-06-05 09:11 UTC, Jambunathan K

Note You need to log in before you can comment on or make changes to this bug.
Description febrezo 2019-12-20 15:33:10 UTC
I am using unicode characters from my Fedora 31 which are included in the text of textboxes in my Libreoffice Impress. The characters are shown perfectly in the .odp file generated, perfectly opened in other applications and perfectly exported to PNG files for example. However, when exporting to PDF the character is not shown and I can see directly nothing in its space. Examples of not printed characteres in PDF files are any of the following: ๐Ÿ™Š, ๐Ÿ“ฅ, ๐ŸŒŽ, ๐Ÿ›ต, ๐Ÿš™, ๐Ÿˆ, ๐Ÿ€, โณ, etc.

Steps to Reproduce:
1. Add a textbox and insert any Unicode emoji ๐Ÿ™Š, ๐Ÿ“ฅ, ๐ŸŒŽ, ๐Ÿ›ต, ๐Ÿš™, ๐Ÿˆ, ๐Ÿ€, โณ, etc.
2. Export to PNG (works, not a problem here)
3. Export to PDF (DOES NOT appear, problem found)

Actual Results:
The emoji is not shown in the PDF exported file

Expected Results:
The emoji should appear as expected

Reproducible: Always

User Profile Reset: No

Additional Info:
Comment 1 V Stuart Foote 2020-01-04 04:20:55 UTC
Can not confirm on Windows builds on Windows 10 64-bit with
Version: (x64)
Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

See attached.

Pasting the string 
 ๐Ÿ™Š, ๐Ÿ“ฅ, ๐ŸŒŽ, ๐Ÿ›ต, ๐Ÿš™, ๐Ÿˆ, ๐Ÿ€, โณ, etc.

into Impress, it will receive fall-back font replacment as the Liberation Sans default font for Impress does not have coverage of the Emoji.

But, that also means there may not be coverage of the glyphs when you export.

Instead you _must_ replace the font in the text box to specify a font with Unicode  coverage and so avoid fall-back mechanisim. And then also be sure to embed the font into the Impress document: from File -> Properties -> Font tab.

So, when you explicitly handle the font specification for Emoji (and other Unicode glyphs), they will export to PDF.

Not sure more can be done with the PDF export handling of fall-back font replacement
Comment 2 V Stuart Foote 2020-01-04 04:23:16 UTC
Created attachment 156922 [details]
ODP and exported PDF with Emoji One Color font embedded
Comment 3 Stanislaus J. Pinasthika 2020-01-20 01:02:32 UTC
I can confirm with my Kubuntu 19.04
Build ID: 5030be4e85179147476b1e441eb618fb6ed58235
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: kf5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-11-28_20:14:48
Locale: id-ID (id_ID.UTF-8); UI-Language: en-US
Calc: threaded


Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: kde5; 
Locale: id-ID (id_ID.UTF-8); UI-Language: en-US
Calc: threaded

it doesn't appear in the pdf
Comment 4 Buovjaga 2020-11-16 13:30:14 UTC
*** Bug 133296 has been marked as a duplicate of this bug. ***
Comment 5 Buovjaga 2020-11-16 13:30:20 UTC
*** Bug 138257 has been marked as a duplicate of this bug. ***
Comment 6 Buovjaga 2020-11-27 12:12:22 UTC
*** Bug 134865 has been marked as a duplicate of this bug. ***
Comment 7 Dieter 2021-02-09 07:21:00 UTC
*** Bug 139892 has been marked as a duplicate of this bug. ***
Comment 8 MGA 2021-02-24 22:10:35 UTC
This appears to be a problem across all LibreOffice applications. I'm encountering it in Writer on Mac.
I'm new here and not a programmer: is there anything I can do to help fix this?
Comment 9 steve 2021-03-07 09:39:29 UTC
*** Bug 140847 has been marked as a duplicate of this bug. ***
Comment 10 steve 2021-03-07 09:46:22 UTC
Providing another data point:

Exporting Stuart's odp test file and saving via โŒ˜P > Save as PDF results in a PDF with all graphics in color. Oddly enough the print preview shows the graphics in greyscale despite having "Original colors" selected (but that would be another bug).

Creating a new writer document, pasting  ๐Ÿ™Š, ๐Ÿ“ฅ, ๐ŸŒŽ, ๐Ÿ›ต, ๐Ÿš™, ๐Ÿˆ, ๐Ÿ€, โณ into it and doing the same also results in a PDF with all the emojis.

So no repro on macOS with latest nightly build:

Version: / LibreOffice Community
Build ID: 3d008f3bcd19a74cff0781cbd9a3d173892553cf
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded

@MGA: Could you try to reproduce the problem with latest nightly build from:
https://dev-builds.libreoffice.org/daily/master/ and report if you are still able to reproduce and if yes, which macOS you are using.
Comment 11 Buovjaga 2021-03-07 10:42:25 UTC
I can't repro on Linux, same as my test in bug 134865 last year. Could everyone please re-test with 7.2? Linux users can grab an appimage https://libreoffice.soluzioniopen.com/
Comment 12 Alberto Salvia Novella 2021-03-07 11:24:21 UTC
As I said, it happens with 7.2:

Those who cannot reproduce the bug, please zip and attach here the contents of "/etc/fonts".
Comment 13 Alberto Salvia Novella 2021-03-07 11:25:34 UTC
By the way, my error log seems to show the culprit of this bug:
Comment 14 Buovjaga 2021-03-07 11:36:04 UTC
Alberto: would be good, if you attached the ODP shown in your screenshot attachment 170281 [details]. You can attach it to the closed report to keep things organised.
Comment 15 Alberto Salvia Novella 2021-03-07 11:40:19 UTC Comment hidden (obsolete)
Comment 16 Alberto Salvia Novella 2021-03-07 11:41:04 UTC Comment hidden (obsolete)
Comment 17 Alberto Salvia Novella 2021-03-07 11:41:36 UTC Comment hidden (obsolete)
Comment 18 Alberto Salvia Novella 2021-03-07 11:42:09 UTC Comment hidden (obsolete)
Comment 19 Alberto Salvia Novella 2021-03-07 11:47:11 UTC Comment hidden (obsolete)
Comment 20 Alberto Salvia Novella 2021-03-07 11:48:46 UTC Comment hidden (obsolete)
Comment 21 Buovjaga 2021-03-07 11:49:12 UTC Comment hidden (obsolete)
Comment 22 Alberto Salvia Novella 2021-03-07 11:50:40 UTC
For this bug, you can try if this fix your problem:
Comment 23 Alberto Salvia Novella 2021-03-07 11:55:24 UTC
I can reproduce my bug with ANY file, with a blank profile. Just by pasting an emoji into it, and that's all.
Comment 24 Alberto Salvia Novella 2021-03-07 12:37:33 UTC
*** Bug 140847 has been marked as a duplicate of this bug. ***
Comment 25 Buovjaga 2021-03-07 12:48:25 UTC
Created attachment 170307 [details]
Buovjaga's /etc/fonts
Comment 26 Alberto Salvia Novella 2021-03-07 13:50:43 UTC
Reproduced with that same configuration, with the following steps:

sudo mv /etc/fonts /etc/fonts-back
sudo cp -r ~/Downloads/etc/fonts /etc/fonts
fc-cache -f -v

I noticed that while not having "/etc/font"s on the filesystem, and regenerating the cache, LibreOffice was still able to show color emoji. When the rest of applications where showing black and white versions of them.

This suggest me that how LibreOffice displays emoji is despite of system configuration, using its own engine.

The culprit seems to be registered in my err.log:

The relevant line is:
xmloff:80621:80621:xmloff/source/style/XMLFontStylesContext.cxx:221: unknown element urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0 svg:font-face-format
Comment 27 Alberto Salvia Novella 2021-03-07 14:33:31 UTC
Reproduced on my OS live image (Manjaro) by using the appimage and noto-fonts-emoji.
Comment 28 Alberto Salvia Novella 2021-03-07 14:57:46 UTC
Also reproduced with Endeavour OS, which also uses Arch Linux packages as base.
Comment 29 Alberto Salvia Novella 2021-03-07 15:23:09 UTC
Reproduced on Ubuntu 20.10.

So the bug must lie withing LibreOffice code.
Comment 30 Alberto Salvia Novella 2021-03-13 04:56:59 UTC
Exporting to PDF from Google Drive results in black silhouettes:
Comment 31 Alberto Salvia Novella 2021-03-13 20:40:22 UTC
Opening the one exported with Google Docs on Firefox shows the emoji correctly, opening the one exported with LibreOffice shows no emoji.
Comment 33 Aron Budea 2021-03-25 00:55:36 UTC
Khaled, I noticed the last sentence in the commit message, could you please elaborate on the reason behind that?

author		Khaled Hosny <khaledhosny@eglug.org>	2019-08-27 15:19:15 +0200
committer	Khaled Hosny <khaledhosny@eglug.org>	2019-09-03 23:48:17 +0200

Make Noto Color Emoji font work on Linux

Noto Color Emoji is a bitmap color font, Cairo knows how to scale such
fonts and FontConfig will identify them as scalable but not outline
fonts, so change the FontConfig checks to checks for scalability.

Make sft.cxx:doOpenTTFont() accept non-outline fonts, the text will not
show in PDF but that is not worse than the status quo.
Comment 34 V Stuart Foote 2021-03-30 21:16:50 UTC
*** Bug 141342 has been marked as a duplicate of this bug. ***
Comment 35 steve 2021-08-12 12:26:53 UTC
There was a similar situation in Firefox on macOS after printing to PDF:
Comment 36 Alexander P 2021-12-18 14:04:32 UTC
Changing version to as the bug is still reproducible with that one.
Comment 37 ebseattle 2022-01-15 21:04:34 UTC
I can confirm that I encountered this in version on MacOS 12.1. A workaround on MacOS is to Print the document, then Save As PDF, but the resulting PDF file is larger and lower in quality than the exported PDF.
Comment 38 Gwendal 2022-02-24 15:25:45 UTC
Can reproduce using version
Comment 39 Yannis Delmas 2022-04-07 09:17:42 UTC
Still present:

Version: (x64) / LibreOffice Community
Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0
CPU threads: 12; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL
Comment 40 Stuardo Rodrรญguez 2022-06-02 12:29:54 UTC
*** Bug 104403 has been marked as a duplicate of this bug. ***
Comment 41 Timur 2022-06-03 09:17:00 UTC
This report has many users and it's duplicated, including See Also bugs and Bug 104403 where Khaled gave some inputs. 
Actually this one was a duplicate at the beginning, but it's late now to change. 
Due to number of reports and user, I set High Major.
Comment 42 Jambunathan K 2022-06-05 05:14:21 UTC
One more upvote from my side ...

I had trouble with the moon symbols.

| *Phase*       | *UCS Codepoint* | *Glyph* |
| New moon      | =U+1F311=       |   ๐ŸŒ‘    |
| First quarter | =U+1F313=       |   ๐ŸŒ“    |
| Full moon     | =U+1F315=       |   ๐ŸŒ•    |
| Last quarter  | =U+1F317=       |   ๐ŸŒ—    |
|               |                 |   <c>   |

LibreOffice was picking up `Noto Color Emoji` on my machine.  Even though the UI was picking up the Colored Emojis, the PDF export part wasn't.  I had to remap `Noto Color Emoji` to `Symbola` font.  (I am on Debian Unstable, and I couldn't find the `Emoji One Color` on the package repos)

  See https://emacs.stackexchange.com/a/72035/31220.

I am also attaching the screenshots.


I don't know much about fonts or if they expose their "capabilities" in useful ways.  If fonts do advertise their capabilities, and LibreOffice's PDF printer doesn't handle those capabilities it should automatically switch to a different "functional" font.  That is, LibreOffice should do a "functional deprecation" instead of a "dysfunctional" export.

In my case, I would have appreciated if LibreOffice PDF export deprecated itself to a "works for me" black and white `Symbola` font instead of the "dysfunctional / not-all-acceptable" `Noto Color Emoji` font.
Comment 43 Jambunathan K 2022-06-05 05:22:37 UTC
Created attachment 180572 [details]
Moon symbols + Noto Color Emoji doesn't render at all on PDF side
Comment 44 Jambunathan K 2022-06-05 05:23:56 UTC
Created attachment 180573 [details]
Moon Symbols: Translate `Noto Color Emoji` to `Symbola`
Comment 45 Jambunathan K 2022-06-05 05:25:33 UTC
Created attachment 180574 [details]
Moon Symbols renders well with `Symbola`
Comment 46 Jambunathan K 2022-06-05 05:26:55 UTC
Created attachment 180575 [details]
Moon symbols:  `fc-list` on my Debian Unstabe (as recent as June 1, 2022)
Comment 47 Jambunathan K 2022-06-05 05:30:56 UTC
Created attachment 180576 [details]
moon-phases.odt: With `Noto Color Emoji` font
Comment 48 Jambunathan K 2022-06-05 05:38:21 UTC
Created attachment 180577 [details]
moon-phases.pdf: `moon-phases.odt` exported  to `PDF` with `Noto Color Emoji` font
Comment 49 Jambunathan K 2022-06-05 05:41:27 UTC
Apropos `moon phases.odt`  & co. report, I am using 

Version: / LibreOffice Community
Build ID: 30(Build:1)
CPU threads: 4; OS: Linux 5.17; UI render: default; VCL: x11
Locale: en-IN (en_IN); UI: en-US
Debian package version: 1:7.3.4~rc1-1
Calc: threaded
Comment 50 Jambunathan K 2022-06-05 06:50:12 UTC
> I am on Debian Unstable

A little usage in the hope that it helps others running in to this issue, and looking for workarounds ....

`Emoji One Color` was mentioned in https://bugs.documentfoundation.org/show_bug.cgi?id=129523#c2,  Since there is no such package in Debian Unstable (dtd. June 2022), I narrowed down to this repo https://github.com/adobe-fonts/emojione-color. 

This repo has a release https://github.com/adobe-fonts/emojione-color/tags which is dated Aug 2017.  5+ years seemed too old to me.  The homepage URL on the repo  https://www.emojione.com/emoji/v2 was re-directing me to a different website which seems to be associated with https://github.com/joypixels/emoji-toolkit.

So, abandoned looking for `Emoji One Color` font, and setlted for https://github.com/adobe-fonts/noto-emoji-svg/releases/tag/2.002.  I settled for this because

- It is from `adobe`(?)
- has "Noto Emoji" in it's name
- .. more importantly it had "Color" in it's name.

This is what I did,

I removed `fonts-noto-color-emoji` that comes with Debian Unstable

~/Downloads$ sudo apt remove fonts-noto-color-emoji

Installed their namesakes from https://github.com/adobe-fonts/noto-emoji-svg/releases/tag/2.002.

~/Downloads$ wget https://github.com/adobe-fonts/noto-emoji-svg/releases/download/2.002/NotoColorEmoji-SVG.otf
~/Downloads$  mv NotoColorEmoji-SVG.otf ~/.local/share/fonts/
~/Downloads$  fc-cache -v

~/Downloads$  wget https://github.com/adobe-fonts/noto-emoji-svg/releases/download/2.002/NotoEmoji.otf
~/Downloads$  cp NotoEmoji.otf ~/.local/share/fonts/
~/Downloads$  fc-cache -v


I am getting a "functional" pdf, without having to setup a font translation table.  Contrary to the word "color" in the font, I am getting a black and white glyph.  Not getting a color in final output PDF is a bit disappointing,  but it "works for me".
Comment 51 Jambunathan K 2022-06-05 07:00:47 UTC
Created attachment 180578 [details]
Moon symbols: Rendered with Noto Emoji SVG;

Font used is from https://github.com/adobe-fonts/noto-emoji-svg/releases/tag/2.002.  I believe this font is derived from `Noto Color Emoji` font with all colors stripped.  PDF export works well, but the moon symbols are in  Black and White.
Comment 52 Jambunathan K 2022-06-05 09:11:20 UTC
Created attachment 180579 [details]

I could no longer locate the `Emoji One Color` font.  So, I am attaching it here in the hope  that it will be helpful.

Extracted from the `odp` file within the [`zip` file`](https://bugs.documentfoundation.org/attachment.cgi?id=156922) shared in [Comment#2](https://bugs.documentfoundation.org/show_bug.cgi?id=129523#c2)
Comment 53 โจุฎุงู„ุฏ ุญุณู†ูŠโฉ 2022-09-13 14:04:31 UTC
*** Bug 144982 has been marked as a duplicate of this bug. ***
Comment 54 โจุฎุงู„ุฏ ุญุณู†ูŠโฉ 2022-09-24 07:04:18 UTC
Bug 104403 and bug 121327 add PDF export support for the 3 most common emoji color fonts (the ones used for the system emoji fonts on Windows, macOS and Linux).

What remains is bug 105488 for color fonts using embedded SVGs (ironically that is the format of the Emoji font we bundle, bug 144348), but even if we supported PDF export Cairo and Skia do not support using SVG color glyphs, so we would need to handle rendering them on screen as well (which is probably wonโ€™t be very performant).

Bug 151057 is for the new COLRv1 fonts which are set to make using SVG glyphs obsolete, but this is very recent and currently only supported by Chrome and upcoming FireFox.

Overall I think the emoji export in PDF should work for most people in 7.5.
Comment 55 Caolรกn McNamara 2022-10-02 12:40:19 UTC
Lets deem this fixed then. And if there are remaining issues that matter, don't reopen this one (54+ comments and multiple similar but distinct subformats is unwieldy), but file a new one.
Comment 56 โจุฎุงู„ุฏ ุญุณู†ูŠโฉ 2022-11-23 06:33:03 UTC
*** Bug 152180 has been marked as a duplicate of this bug. ***
Comment 57 โจุฎุงู„ุฏ ุญุณู†ูŠโฉ 2022-11-24 06:38:18 UTC
*** Bug 152180 has been marked as a duplicate of this bug. ***