When using color emoji fonts such as Segoe UI Emoji in LibreOffice Writer, the emojis are displayed correctly on screen but are printed only in black and white. This behavior differs from Microsoft Word and Web Office, which correctly print these emojis in full color. This issue is a significant obstacle for users transitioning from MS Word to LibreOffice, especially when working with documents that rely on visual clarity or expressive content. I frequently find myself switching back to Word just to get proper print output – even though I would prefer to stay in LibreOffice. It would be extremely helpful if LibreOffice Writer could support color printing for emoji fonts, especially widely used ones like Segoe UI Emoji on Windows systems. Thanks for considering this enhancement and for your continued work on improving LibreOffice!
What version of Windows and (if possible) what is the Segoe UI Emoji version. Newer versions of the font use COLR v1 table which we do not currently support (bug 151057).
I'm using Windows 10, version 10.0.19045.6332. The version of Segoe UI Emoji installed on my system is 1.29. Hope this helps resolving!
The version 1.29 of Segoe UI Emoji still uses version 0 of COLR table and this should be supported. I can’t reproduce the issue on macOS using Segoe UI Emoji from Windows 10 and LibreOfice 25.8.1.1, so it might be a Windows-only issue.
I dont know what supported in this case means. On the Screen the font is displayed in colors without mistake. Only when printing, it is black and white, so it seems only partly supported on windows? It looks like a Problem of Libre Writer printing process, coz if I make an export into PDF 1.7 then the font is displayed and printed correctly with my PDF program.
(In reply to Christian from comment #4) > I dont know what supported in this case means. On the Screen the font is > displayed in colors without mistake. Only when printing, it is black and > white, so it seems only partly supported on windows? > It looks like a Problem of Libre Writer printing process, coz if I make an > export into PDF 1.7 then the font is displayed and printed correctly with my > PDF program. OK, I missed the printing bit (or my mind equated printing with PDF export). I only tested PDF export, and it works for me as well. I’m on macOS which uses PDF for printing (the same is true for Linux, IIRC), so this is indeed a Windows-only issue. I don’t know much about printing on Windows (except that it does not use PDF, at least in LibreOffice), and when I worked on color fonts support I only worked on PDF export.
The font on my Windows is unfortunately too new and all the 1.29 ones I found are invalid in Windows's opinion. I was going to try and study the created .spl file per what is discussed in https://superuser.com/questions/1680367/how-can-i-intercept-the-contents-of-a-windows-spool-file https://stackoverflow.com/questions/11420237/intercepting-data-sent-to-a-windows-printer-using-redmon When navigating to the Control Panel\Hardware and Sound\Devices and Printers folder, we can right-click a printer and select Printer Properties. There, click Change Properties button first. Then in Advanced tab, activate "Keep printed documents". Now the .spl files should remain in C:\Windows\System32\spool\PRINTERS and we might look at them with https://splview.software.informer.com/ or some other program. Doing it like this would hopefully avoid wasting paper when investigating, if this is a regression. I don't even have a physical printer right now, so there's also that...