Bug 160884 - Noto Color Emojis vertically misaligned in exported PDFs
Summary: Noto Color Emojis vertically misaligned in exported PDFs
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: ⁨خالد حسني⁩
URL:
Whiteboard: target:24.8.0 target:24.2.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2024-05-01 09:27 UTC by Mel
Modified: 2024-05-20 08:46 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
Comment 4 ⁨خالد حسني⁩ 2024-05-18 14:16:29 UTC
(In reply to Stéphane Guillou (stragu) from comment #2)
> 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?

No working build environment so I can’t test a fix, but I have a hunch what got wrong. If I submit a gerrit change will you be able to test it and verify if fixes the issue?
Comment 5 ⁨خالد حسني⁩ 2024-05-18 14:18:53 UTC
(In reply to V Stuart Foote from comment #3)
> 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.

The new Noto Color Emoji uses COLR v1 table which we do not yet support: Bug 151057, the issue here is about the old font which uses color bitmaps.
Comment 6 Stéphane Guillou (stragu) 2024-05-19 06:09:44 UTC
(In reply to ⁨خالد حسني⁩ from comment #4)
> No working build environment so I can’t test a fix, but I have a hunch what
> got wrong. If I submit a gerrit change will you be able to test it and
> verify if fixes the issue?
Thanks Khaled. Done, replied on Gerrit.
Comment 7 Commit Notification 2024-05-19 07:30:41 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/44f2bc12779645bce1000289caf9c66804ecb14e

tdf#160884: Apply scale to position of embedded images in Type 3 fonts

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Mel 2024-05-20 06:15:02 UTC
Confirmed that this is fixed in the latest daily. Thanks folks! :)
Comment 9 Commit Notification 2024-05-20 08:46:33 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/af319f4122aab98d44e88e8d582c109096c57049

tdf#160884: Apply scale to position of embedded images in Type 3 fonts

It will be available in 24.2.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.