Bug 104403 - Support multi-colored fonts using COLR/CPAL tables
Summary: Support multi-colored fonts using COLR/CPAL tables
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: ⁨خالد حسني⁩
URL:
Whiteboard: target:7.5.0 inReleaseNotes:7.5
Keywords:
: 115848 (view as bug list)
Depends on: HarfBuzz
Blocks: Font-Rendering 129523
  Show dependency treegraph
 
Reported: 2016-12-05 06:09 UTC by ⁨خالد حسني⁩
Modified: 2022-12-10 22:34 UTC (History)
24 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file with results for LO 7.5 alpha1+, on Windows 10 and Ubuntu 20.04 (349.83 KB, application/vnd.oasis.opendocument.text)
2022-12-08 17:28 UTC, Stéphane Guillou (stragu)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ⁨خالد حسني⁩ 2016-12-05 06:09:43 UTC
Description:
The latest version of the OpenType specification introduced few tables that allow for having multi-colored glyphs.

The simplest of them is COLR/CPAL (https://www.microsoft.com/typography/otspec/colr.htm, https://www.microsoft.com/typography/otspec/cpal.htm) which uses layers of normal glyphs and color palettes to assign colors to each.

It shouldn’s be hard to parse the tables in SalGraphics::DrawTextLayout() and draw each layer glyph with its assigned color. We might want to wait until HarfBuzz supports these fonts to avoid parsing the tables on our own.

This would allow supporting fonts like Amiri Quran Colored or several of the new Emoji fonts cross-platform (Windows 8.1+ already supports this format, though I don’t think we make use of that support).

Steps to Reproduce:
Try using Amiri Quran Colored font with Arabic text.

Actual Results:  
Text comes out using the foreground color.

Expected Results:
Text should use the colors defined in the font.


Reproducible: Always

User Profile Reset: 

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Volga 2016-12-05 10:02:49 UTC Comment hidden (obsolete)
Comment 2 Volga 2017-01-23 04:07:41 UTC Comment hidden (obsolete)
Comment 3 V Stuart Foote 2018-02-19 18:21:57 UTC
*** Bug 115848 has been marked as a duplicate of this bug. ***
Comment 4 Volga 2018-02-28 15:05:03 UTC Comment hidden (no-value)
Comment 5 Volga 2018-03-01 02:53:30 UTC Comment hidden (no-value)
Comment 6 Volga 2018-03-01 14:40:05 UTC
They has an issue for discussing the API, so we can track it to see the results.
https://github.com/harfbuzz/harfbuzz/issues/849
Comment 7 Volga 2018-03-08 01:30:15 UTC Comment hidden (no-value)
Comment 8 Volga 2018-03-10 02:34:29 UTC Comment hidden (obsolete)
Comment 9 Volga 2018-11-06 00:34:16 UTC
This feature is already available in HarfBuzz since 2.1.0.
Comment 10 Aleksandr Andreev 2019-04-06 19:32:36 UTC
What's the status with this? How difficult would it be to support this now that it is supported by HarfBuzz?
Comment 11 ⁨خالد حسني⁩ 2019-04-06 20:05:50 UTC
(In reply to Aleksandr Andreev from comment #10)
> What's the status with this? How difficult would it be to support this now
> that it is supported by HarfBuzz?

For screen rendering they should already supported on Linux if you have FreeType 2.10.x and Cairo 1.16.x, and should be supported on recent enough macOS systems (disdn’t test that, though). On Windows it would require calling the relevant DirectWrite APIs (https://docs.microsoft.com/en-us/windows/desktop/directwrite/color-fonts#using-color-fonts-with-directwrite-and-direct2d)

For PDF, we would need to call HarfBuzz to decompose the color glyph layers before writing them to the PDF, should be a couple of days work or so if someone is interested.
Comment 12 Aleksandr Andreev 2020-09-06 18:51:21 UTC
If someone is interested in taking up this issue, please contact me. I am willing to offer a bounty for the resolution of this issue.
Comment 13 Martin Monperrus 2022-02-05 12:07:17 UTC
I confirm I cannot print or pdf-export documents with emojis today:

Libreoffice 6.4.7.2 40(Build:2)
Emojis: fonts-noto-color-emoji

Now following this important bug.

(coming from https://askubuntu.com/questions/1279100/emoji-disappear-when-i-print-export-to-pdf-or-download-a-pdf-after-update-to-2)
Comment 14 Stuardo Rodríguez 2022-06-02 12:29:54 UTC
Isn't this a duplicate of #129523?

*** This bug has been marked as a duplicate of bug 129523 ***
Comment 15 ⁨خالد حسني⁩ 2022-08-12 17:25:23 UTC
This is not a duplicate, different color font technologies need totally different handling. Each needs a separate tracking bug.
Comment 16 Commit Notification 2022-09-19 11:39:03 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

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

vcl: tdf#104403 PDF export for layered color fonts

It will be available in 7.5.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 17 ⁨خالد حسني⁩ 2022-09-19 11:41:33 UTC
The PDF export is handled with the above commit, on screen rendering is handled by the respective graphics libraries on each systems and should probably work on all platforms supported by LibreOffice, but if it does not work on a certain platform please report, we might be able to add some fallback code to on screen rendering.
Comment 18 Stéphane Guillou (stragu) 2022-12-08 17:28:19 UTC
Created attachment 184054 [details]
Test file with results for LO 7.5 alpha1+, on Windows 10 and Ubuntu 20.04

Tested with Bungee Color Fonts (COLRv0 and COLRv1) from https://github.com/djrrb/Bungee/releases/tag/v1.2.0

On Windows 10, it is still displayed garbled in Writer (as predicted by Khaled), but the PDF export of COLRv0 looks good.

Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: c50cf1883af26daebdfc9d796ced3c20c222f43b
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

On Ubuntu 20.04, it is displayed well in app, and the COLRv0 version looks good in export too.

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

(I had to open the PDF in Firefox as Evince would display everything black)

I am however not sure what to make of the COLRv1 version displaying black in both app and export.

Thoughts, Khaled? Needs a follow-up report?

In any case, marking this one as verified given the improvement in PDF export between 7.4 and 7.5 (for both Windows and Linux).
Comment 19 ⁨خالد حسني⁩ 2022-12-10 13:33:54 UTC
(In reply to Stéphane Guillou (stragu) from comment #18)
> Created attachment 184054 [details]
> Test file with results for LO 7.5 alpha1+, on Windows 10 and Ubuntu 20.04
> 
> Tested with Bungee Color Fonts (COLRv0 and COLRv1) from
> https://github.com/djrrb/Bungee/releases/tag/v1.2.0
> 
> On Windows 10, it is still displayed garbled in Writer

This is a font issue due to some weird limitation on Windows implementation of COLRv0 table that is often overlooked. I reported it here:
https://github.com/djrrb/Bungee/issues/86

> Evince would display everything black

This is a Cairo bug, it is fixed but probably most distros are still using old version:
https://gitlab.freedesktop.org/cairo/cairo/-/issues/389

Every other PDF viewer I tested works fine.

> I am however not sure what to make of the COLRv1 version displaying black in
> both app and export.
> 
> Thoughts, Khaled? Needs a follow-up report?

We already have bug 151057. COLORv1 is too new, currently only Chrome and beta versions of Firefox support it, so it will be a while before the graphics libraries we use support it (and some systems like Windows 8 or 10 probbaly will never get it, unless we can use Skia the way Chrome uses it to get around system limitations). PDF export will take some effort as well, but if we can’t render it on screen it will be rather pointless.
Comment 20 Stéphane Guillou (stragu) 2022-12-10 22:34:23 UTC
Fabulous, thank you for the thorough response, Khaled.