I was not really sure whether to file this under bugs or feature requests. When looking up this error I see other places where it was just a matter of not including the correct font packs, but I am not really sure that applies here. Is this part of a font? If so, which? Can Prince be updated to include some special characters such as this which aren't really a part of any font? Or can you point me to what font I need to include to have things like this work as a fallback renderer for these?
This character will be supported by an emoji font presumably, but I'm not sure which one. Prince doesn't support color fonts yet, so if you need colorful emoji it will be necessary to replace this character with an image.
@font-face {
font-family: 'Emoji';
src: local('Emoji'), url('font/NotoEmoji-Regular.ttf') format('truetype');
}
body {
font-family: open sans, emoji;
}
I wish Google would add fonts like that to their Google Font sets so I didn't have to self-host, but oh well. It might also be worth your time to embed something like this as a fallback for Prince since I imagine as emoji gets more common I won't be the only one requesting this. Thanks for pointing me in the right direction.
PS: It's not a big deal to me, but if you ever get colored font support let me know so I can update to a colored set!
It is planned to be added; might take a little while though as there are four different formats for representing them. In the meantime you can perhaps replace them with SVG or PNG images.
Emoji One is no longer open source so I'm attempting to use Noto Emoji. It works, and I get black and white emoji, but variation selectors still appear as question marks. Many emoji consist of a codepoint followed by a variation selector, so in the output I see an emoji followed by a question mark.
Is there a way I can suppress those question marks from appearing?
Were you able to get it to display in black and white in the browser as well? I was originally using Noto Emoji because they had a pack that was black and white only for both browsers and Prince rendering, but it is increasingly getting out of date and I keep having users put in stuff I don't support. If I use "twemoji-color-font" it has a much better distribution of emojis, but it gives the user the false impression that they will get a color emoji from the render
I am having even more fun with this with multi-part emoji such as 🤦♂️. That emoji displays completely funky with the black & white version of Noto Emoji. I see that you guys recently started working on color emoji with: https://www.princexml.com/roadmap/
Support color emoji fonts in CBLC/CBDT format, such as Noto Color Emoji and JoyPixels (limited to 256 emoji per font for now). (ref) Done 2020-06-11
I download the latest Prince snapshot to play around with it, but realized that that latest build at https://www.princexml.com/latest/ is 05/04/2020. Any chance of getting a new build out so I can play with some wonderful color emoji support? Also, is the 256 emoji font limit meaning that a regular Noto Color Emoji.tff won't work, or just that it can only use up to 256 fonts from that file at a time? I am really looking forward to this!
The latest build with emoji support is now available! There are some issues we are still working on: using more than 256 emoji glyphs as mentioned earlier, and also support for emoji tag sequences needed for some flags.
It is wonderful! I attached a sample now with color emoji and it looks good. Thank you so much for adding this feature! If you remember about this still whenever you have a build that support more than 256 emoji glyphs can you post it in this thread so I can update again?
It looks like when rendered as a jpg the emoji are black and white. I have attached an example. Ignore the color emoji example at the top. It is an image rendered separately and embedded in the pdf.
I allow customers to choose between layered or flattened pdfs to render since some want to be able to move text boxes and such around and some people have printers that can't handle all pdfs generated by Prince. I didn't notice this until I started working on some regression testing for the new build.
We didn't add anything into header for emoji font, do you have an example of how to make it work with emojis? It was the html character in the SVG (no filters)
Prince defaults to "Noto Color Emoji", but if this font is not installed it may end up using another font that only has black and white glyphs for those characters. You can also access this font via HTTP but it will be more efficient to have it as a local file.
Thanks for this, it seems the font file from Google is very large, if not installed on the system do we need to host and reference every font file via http?
1. Installing them as system fonts and referring to them by family name "Noto Color Emoji" 2. Saving them as local files and using a @font-face rule to refer to them by filename 3. Accessing them on the web and using a @font-face rule to refer to them by HTTP URL
Since it is a large font and you don't want Prince to download it every time it is probably best to save it as a local file. You can generate a CSS font-face rule for it by running "prince --scanfonts NotoColorEmoji.ttf".
Today we have an updated latest build of Prince that supports emoji rasterisation for image output and filters, it also supports using more than 256 emoji from a single font and the emoji tag sequences needed for some flags.
One more latest build, now with support for OpenType SVG fonts like the Twitter Emoji font! I think this brings our emoji support to a successful conclusion.
(despite the name it also contains black and white emoji)
