Bug 2436684 - COLRv1 breaks Libreoffice PDF export and printing
Summary: COLRv1 breaks Libreoffice PDF export and printing
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: google-noto-emoji-fonts
Version: 43
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL: https://bugs.documentfoundation.org/s...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-02-04 11:19 UTC by ValdikSS
Modified: 2026-08-21 12:44 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description ValdikSS 2026-02-04 11:19:52 UTC
google-noto-emoji-fonts 20241008-3 introduced COLRv1 font format, which is not supported by LibreOffice: it is correctly shown on screen, but fails to render on PDF export or on document printing.

Downgrading to google-noto-color-emoji-fonts-20241008-2.fc42 fixes the issue.

Reproducible: Always

Steps to Reproduce:
1. Make a LibreOffice Writer document with color emoji from Noto Color Emoji font
2. Export it to PDF with the default settings, or print it on a printer
Actual Results:
No emoji, empty character

Expected Results:
Emoji is rendered correctly

Additional Information:
https://bugzilla.redhat.com/show_bug.cgi?id=2371125
https://bugs.documentfoundation.org/show_bug.cgi?id=170590

Comment 1 Jens Petersen 2026-05-26 07:15:01 UTC
I think we should also provide the non-COLR fonts in a subpackage.

Comment 2 Akira TAGOH 2026-08-21 12:39:34 UTC
I'd say that should be LibreOffice issue. It is obvious since same issue doesn't happen on GNOME applications for example.

Shipping the bitmap color emoji requires extra effort. they basically have same family name and we can't mix up different content with the same name. The only way to detect the difference between COLRv1 and the bitmap color one is whether they have outline=True or not. but unfortunately outline property is lower priority than others and requesting it with :family=emoji:outline=false doesn't work. the rest of piece is antialias and pixelsize. it isn't available in COLRv1 one because it is an outline font. So one needs to set proper values to them to leave the decision to outline property.

To demonstorate how it works:

bash-5.3$ fc-match "Noto Color Emoji"
Noto-COLRv1.ttf: "Noto Color Emoji" "Regular"
bash-5.3$ fc-match "Noto Color Emoji":outline=false
Noto-COLRv1.ttf: "Noto Color Emoji" "Regular"
bash-5.3$ fc-match "Noto Color Emoji":outline=false:antialias=false
Noto-COLRv1.ttf: "Noto Color Emoji" "Regular"
bash-5.3$ fc-match "Noto Color Emoji":outline=false:antialias=false:pixelsize=109
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
bash-5.3$ fc-query -f "%{family}:%{outline}:%{antialias}:%{pixelsize}\n" Noto-COLRv1.ttf 
Noto Color Emoji:True::
bash-5.3$ fc-query -f "%{family}:%{outline}:%{antialias}:%{pixelsize}\n" NotoColorEmoji.ttf 
Noto Color Emoji:False:False:109

Comment 3 ValdikSS 2026-08-21 12:44:22 UTC
>I'd say that should be LibreOffice issue. It is obvious since same issue doesn't happen on GNOME applications for example.

It's worth to providing some kind of workaround until LibreOffice implements COLRv2 support.
Right now I'm using older google-noto-color-emoji-fonts-20241008-2.fc42.noarch because I need to print documents with emojis (pictograms really).

Maybe even make a fontconfig emoji font rewrite only for LO with an additional fc config?


Note You need to log in before you can comment on or make changes to this bug.