Bug 2436684

Summary:	COLRv1 breaks Libreoffice PDF export and printing
Product:	[Fedora] Fedora	Reporter:	ValdikSS <iam>
Component:	google-noto-color-emoji-fonts	Assignee:	Mike FABIAN <mfabian>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	mfabian, pwu
Target Milestone:	---	Keywords:	Desktop, Regression
Target Release:	---
Hardware:	Unspecified
OS:	Linux
URL:	https://bugs.documentfoundation.org/show_bug.cgi?id=170590
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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?