Bug 160884 - Noto Color Emojis vertically misaligned in exported PDFs
Summary: Noto Color Emojis vertically misaligned in exported PDFs
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2024-05-01 09:27 UTC by Mel
Modified: 2024-05-16 12:26 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
PDF containing misaligned emoji (30.04 KB, application/pdf)
2024-05-01 09:27 UTC, Mel
Details
ODT file used to export the broken PDF (10.15 KB, application/vnd.oasis.opendocument.text)
2024-05-01 09:28 UTC, Mel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mel 2024-05-01 09:27:15 UTC
Created attachment 193915 [details]
PDF containing misaligned emoji

Emojis on a line of text in an exported PDF are not vertically aligned with the text as they appear in LibreOffice itself, but shifted down significantly.

1. Create a new Writer document
2. Type a line of text and insert an emoji
3. Export document to PDF
4. 👀


Notes:

- Broken in package from Debian testing repo: 4:24.2.0-1  (which is "24.2.0.3 (X86_64)")
- Broken in debs downloaded from libreoffice.org: 24.2.2.2
- Broken in both Writer and Calc (at least)
- Works as expected in LibreOffice 7.6.6 (either from libreoffice.org, or the package that was previously in Debian Testing)

- Font used in my example document is Liberation Serif
- The emojis that get used seem to be sourced from Noto Sans
- Emojis native to the font specified in the document do *not* get shifted down (eg. checkmark in FreeSans)

- Locale: en-GB (en_GB.UTF-8); UI: en-GB
Comment 1 Mel 2024-05-01 09:28:32 UTC
Created attachment 193916 [details]
ODT file used to export the broken PDF
Comment 2 Stéphane Guillou (stragu) 2024-05-16 11:34:52 UTC
Thanks for the report, Mel!

Reproduced in recent daily build:

Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 658a212585c56540a17c41111e6829716d4ef4e3
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Not reproduced in 7.6.7.2 -> regression.

Bibisected with linux-64-24.2 repository to first bad build [2ad2d0298a6de3d1b7175178e326ee0e8fca2afd] which points to:

commit bc3f6c3a47411a3b5dafadca4e5c55cd24e30662
author	Khaled Hosny 	Tue Aug 22 10:47:33 2023 +0300
committer	خالد حسني 	Tue Aug 22 11:45:31 2023 +0200
tdf#155610: Workaround Acrobat bug with Type 3 fonts and unusual UPEM
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155935

Khaled, any chance you could have a look?
Comment 3 V Stuart Foote 2024-05-16 12:26:26 UTC
On Windows builds, which will fallback and use 'Segoe UI Emoji' for the color emojis, the glyphs appear on canvas and are subset into the exported PDF.

Only if I download and install the OFL 'Noto Color Emoji' (2.042) from GoogleFonts, when applied to the span (by selection) they do not show on the LibreOffice document canvas, nor are they visible on export print to PDF--though the font shows as subset embedded to the PDF.

Additionally, if I Alt+X convert to glyph so showing its unicode U+2705 and U+1f60a strings on LO canvas--the number glyphs do not appear (light or gray canvas) so I see U+ and U+    a.  Something is very off with the font.

Similar result if I copy paste the strings with Noto Color Emoji into MS Wordpad

I know the Noto Color Emoji is appealing OFL, and may be default fallback in some os/DE--but this kind of feels => NOB

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded