Bug 129523 - FILESAVE Emojis not exported to PDF
Summary: FILESAVE Emojis not exported to PDF
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.3.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 133296 134865 138257 139892 140847 141342 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2019-12-20 15:33 UTC by febrezo
Modified: 2021-08-12 12:26 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
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
Details
1 On LibreOffice.jpg (375.84 KB, image/jpeg)
2021-03-07 11:40 UTC, Alberto Salvia Novella
Details
2 On PDF export.png (183.70 KB, image/png)
2021-03-07 11:41 UTC, Alberto Salvia Novella
Details
3 On any other application.jpg (428.08 KB, image/jpeg)
2021-03-07 11:41 UTC, Alberto Salvia Novella
Details
err.log (13.91 KB, text/plain)
2021-03-07 11:42 UTC, Alberto Salvia Novella
Details
Buovjaga's /etc/fonts (23.83 KB, application/gzip)
2021-03-07 12:48 UTC, Buovjaga
Details

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
Description:
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: 6.4.0.1 (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
Version: 6.5.0.0.alpha0+
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

and 

Version: 6.3.4.2
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 7.1.0.3 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: 7.2.0.0.alpha0+ / 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:
https://bug-attachments.documentfoundation.org/attachment.cgi?id=170280

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:
https://bugs.documentfoundation.org/attachment.cgi?id=170283
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:
https://gitlab.com/es20490446e/emoji.conf
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
reboot

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:
https://bugs.documentfoundation.org/attachment.cgi?id=170283

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:
https://i.imgur.com/5YWAZHM.png
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?

https://cgit.freedesktop.org/libreoffice/core/commit/?id=dcf7792da2aa2a1ef774a124f7b21f68fff0fd15
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:
https://bugzilla.mozilla.org/show_bug.cgi?id=1723787