Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bad digits with emoji fonts #1354

Closed
mhosken opened this issue May 13, 2021 · 4 comments
Closed

Bad digits with emoji fonts #1354

mhosken opened this issue May 13, 2021 · 4 comments
Labels
bug Existing features not working as expected

Comments

@mhosken
Copy link

mhosken commented May 13, 2021

This sample:

<html><header/><body>
<p style="font-family: sans">U+0031, U+0E41</p>
<p style="font-family: sans, &quot;Noto Color Emoji&quot;">U+0031, U+0E41</p>
</body></html>

Renders the first line correctly, but messes up the second line badly, with evince complaining some font thing failed.

I suspect a problem with Pango, but I can't see where. Digits are keycap characters, but only keycap characters with zwj between or with a VS16 are supposed to be considered emoji characters.
@liZe
Copy link
Member

liZe commented May 16, 2021

with evince complaining some font thing failed

Hello!

Do you use Cairo 1.17.4? If so, this bug is a duplicate of #1292 that you can fix by downgrading Cairo or using a patched version of Cairo (some Linux distributions already have the patch in their latest version).

@mhosken
Copy link
Author

mhosken commented May 26, 2021 •
edited
Loading

I don't think so. I am running libcairo 1.16.0 as found in Ubuntu 20.04. It also fails on latest MacOS (hard to identify but 1.16.0 from homebrew) with no complaints from its PDF viewer.

What's happening is that Pango is saying the digits in the text need to come from the Emoji font and are emoji and yet should be coming from the main sans font. As stated before, I can find nothing in the Pango source that would imply that this has to happen since the rules say you have to have zwj and VS16 in the text string. The resulting PDF has both the sans and the Emoji fonts in and switches between them in the page output, but the Emoji font has not digit characters (obviously) hence the problematic rendering.

@liZe
Copy link
Member

liZe commented May 26, 2021

I don’t have the error in Evince. Here is the PDF I get:

emoji.pdf

Numbers of the second line are emojis from Noto. The Noto Emoji font has these numbers, that’s where the bitmap numbers come from.

I suspect a problem with Pango, but I can't see where. Digits are keycap characters, but only keycap characters with zwj between or with a VS16 are supposed to be considered emoji characters.

Maybe we don’t use Pango as we should.

Even with the current master branch (where Cairo has been removed and colored emojis don’t work), we have emojis (actually empty spaces because it’s broken) instead of normal numbers. At least we know that it’s not a problem with Cairo.

@liZe liZe added the bug Existing features not working as expected label May 26, 2021
@liZe
Copy link
Member

liZe commented Aug 17, 2021

Must be fixed in #1406.

@liZe liZe closed this as completed Aug 17, 2021
@mormahr mormahr mentioned this issue Dec 4, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Existing features not working as expected
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@liZe @mhosken