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:
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
Created attachment 156922 [details] ODP and exported PDF with Emoji One Color font embedded
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
*** Bug 133296 has been marked as a duplicate of this bug. ***
*** Bug 138257 has been marked as a duplicate of this bug. ***
*** Bug 134865 has been marked as a duplicate of this bug. ***
*** Bug 139892 has been marked as a duplicate of this bug. ***
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?
*** Bug 140847 has been marked as a duplicate of this bug. ***
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.
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/
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".
By the way, my error log seems to show the culprit of this bug: https://bugs.documentfoundation.org/attachment.cgi?id=170283
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.
Created attachment 170300 [details] 1 On LibreOffice.jpg
Created attachment 170301 [details] 2 On PDF export.png
Created attachment 170302 [details] 3 On any other application.jpg
Created attachment 170303 [details] err.log
Sorry, this is not the same bug as mine. As I can see the same monocrome emojis on my screen: https://i.imgur.com/viUb97S.png
Please remove my attachments.
Alberto: you reuploaded the attachments from your closed report. Sorry, but this is not what I asked you to do. Once you upload something to one report, you never have to reupload them again as you can reference them by their ID. I asked you to upload the ODP file into your own report.
For this bug, you can try if this fix your problem: https://gitlab.com/es20490446e/emoji.conf
I can reproduce my bug with ANY file, with a blank profile. Just by pasting an emoji into it, and that's all.
Created attachment 170307 [details] Buovjaga's /etc/fonts
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
Reproduced on my OS live image (Manjaro) by using the appimage and noto-fonts-emoji.
Also reproduced with Endeavour OS, which also uses Arch Linux packages as base.
Reproduced on Ubuntu 20.10. So the bug must lie withing LibreOffice code.
Exporting to PDF from Google Drive results in black silhouettes: https://i.imgur.com/5YWAZHM.png
Opening the one exported with Google Docs on Firefox shows the emoji correctly, opening the one exported with LibreOffice shows no emoji.
Could this be the cause? https://gitlab.freedesktop.org/poppler/poppler/-/issues/842 https://gitlab.freedesktop.org/poppler/poppler/-/issues/729
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.
*** Bug 141342 has been marked as a duplicate of this bug. ***
There was a similar situation in Firefox on macOS after printing to PDF: https://bugzilla.mozilla.org/show_bug.cgi?id=1723787
Changing version to 7.2.4.1 as the bug is still reproducible with that one.
I can confirm that I encountered this in version 7.2.5.2 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.
Can reproduce using version 7.2.5.2.0+
Still present: Version: 7.3.2.2 (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
*** Bug 104403 has been marked as a duplicate of this bug. ***
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.
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.
Created attachment 180572 [details] Moon symbols + Noto Color Emoji doesn't render at all on PDF side
Created attachment 180573 [details] Moon Symbols: Translate `Noto Color Emoji` to `Symbola`
Created attachment 180574 [details] Moon Symbols renders well with `Symbola`
Created attachment 180575 [details] Moon symbols: `fc-list` on my Debian Unstabe (as recent as June 1, 2022)
Created attachment 180576 [details] moon-phases.odt: With `Noto Color Emoji` font
Created attachment 180577 [details] moon-phases.pdf: `moon-phases.odt` exported to `PDF` with `Noto Color Emoji` font
Apropos `moon phases.odt` & co. report, I am using Version: 7.3.4.1 / 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
> 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".
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.
Created attachment 180579 [details] Font_EmojiOne_Color_1.ttf 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)
*** Bug 144982 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 152180 has been marked as a duplicate of this bug. ***