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.
Text comes out using the foreground color.
Text should use the colors defined in the font.
User Profile Reset:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
We can expect this pull request will be merged to get support for CPAL table.
We can also explore how Firefox implemented.
*** Bug 115848 has been marked as a duplicate of this bug. ***
HarfBuzz received the following pull request recently:
The above request add support for CPAL table. Now HarfBuzz received the following pull request for COLR table:
They has an issue for discussing the API, so we can track it to see the results.
It’s coming in HB 1.7.6.
Althrough HarfBuzz added support in version 1.7.6, there is no APIs published to use them. So we should waitimg for new release, or giving a hand to fix it soon.
This feature is already available in HarfBuzz since 2.1.0.
What's the status with this? How difficult would it be to support this now that it is supported by HarfBuzz?
(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.
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.
I confirm I cannot print or pdf-export documents with emojis today:
Libreoffice 18.104.22.168 40(Build:2)
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)
Isn't this a duplicate of #129523?
*** This bug has been marked as a duplicate of bug 129523 ***
This is not a duplicate, different color font technologies need totally different handling. Each needs a separate tracking bug.
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":
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:
Affected users are encouraged to test the fix and report feedback.
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.