-
Notifications
You must be signed in to change notification settings - Fork 233
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.
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
Support color fonts #487
Comments
I will try to look into this. Although I'm not sure what I'm getting myself into. xD |
Very bad time 😄 I've mentioned main issues with text handling here recently: linebender/tiny-skia#1 (comment) Also, just a heads up, but "bitmap fonts" are a bit of a mess of a term. What we need is Emojis support, which in TrueType terms means:
As you can guess, the first step would be to write a TrueType glyph rasterization library. Well, unless you plan to stick with sbix/CBLC+CBDT. Overall, I would say the step number 1 would be to untie the current implementation from operation strictly on path outlines. Meaning we have to do layout purely on glyph ids and then fetch/render/cache required glyphs. I have a lot of ideas, but barely any time. For me, this is the next big PS: oh yeah, embedded SVG fonts + WOFF support is also kinda part of it. After all, SVG is mostly about text and nothing else. |
I looked a bit into it. I agree that in the long term, it would probably be best to have text just contain a number of glyphs as well as their position, and then just render them correspondingly. Eventually, I plan to implement text selection for What do you think if we try this is a "stopgap" approach until we have something better: Right now, an
And then we basically just render the group as is. I'm not sure if I'm missing something. But I've managed to change the current implementation so that it works with Path nodes and it seems to work fine, so next I could look into whether it actually works with bitmap emojis. If you think that this approach is worth pursuing for now. |
Regarding SVG, when you refer to having to write a custom parser I presume that you are referring to the fact that some elements must be ignored according to the specification (e.g. text, stylesheets, etc.)? But I'm really not sure if it's worth it to write a custom parser for that... Maybe we can instead add options to usvg to ignore such elements? Not sure. But for now, it should be fine to just use the existing EDIT: Nevermind, I should've kept on reading... There is more stuff that we need to support. |
But the more I think about it, maybe it's indeed best to first rewrite the current code to contain positioned glyphs which are then subsequently turned into paths, and then worry about how to best deal with emojis... Will try to look into it. |
If I recall correctly, the two main issues with TrueType SVG are: CSS 3/4 features which we do not support (namely computed values) and an ability to reference other glyph (aka As for the "next step" - it doesn't really matter to me. The reason I would suggest starting with separating layout and outlines is because outlines can be freely scaled, but bitmap fonts can't. Meaning we have to either get the bigger bitmap from the font and downscale it or somehow dynamically choose which bitmap size to render. |
I'll keep you posted! I have some ideas I will try out. |
So we have glyph layouts now, so once I find the time I will try to work on this (for now just bitmap emojis) in the next few days/weeks. But my question is: Do you know any fonts that I can use to test all of the legacy bitmap formats? I can use Apple Color Emoji to test sbix, and I think older version of Noto Color Emoji use CBLC + CBDT. But any idea for where I can fonts for the older ones? Basically, I'd like to have one font for each of the formats that |
Or would you accept a PR that implements this just for PNG bitmaps for now? |
Well, that the trick - there are none. The only Let's stick with PNG for now. |
|
Nope, in this case all glyph raster images have |
My best guess would be that it is somehow aligned to the descender of the font? But I don't see this being described anywhere... |
Hmm, Apple emojis are rendered "below" the baseline in Firefox and Safari as well, so we definitely have to account for something, but I have no idea for what. rustybuzz seems to be producing the correct output as well:
|
Yeah I really have no idea... The width seems to be just fine, there really is just some shift on the y-axis for some reason. |
Would it be okay for you if for now I just try to find a magic value that at least works with Apple Color Emoji and Noto Color Emoji? I will also add some tests to make sure it also works for different font sizes. I'm not sure what else I could do. |
Not ideal, but good enough. |
Welp... using a magic value that works for Apple Color Emoji does not work for Noto Color Emoji. 🥲 So yeah... I guess we're stuck for now. |
I was expecting you hardcode an offset per font family. |
Ah... Yeah I guess this could be a last resort option. |
Can you also publish your changes so I could test them locally. |
Yes, sorry, I'll try to clean it up and upload it within the next few days. |
See #735. |
I suggest changing the title of this issue to Because color fonts are not just emoji, it is a broad font technology, emoji is just one of its usage scenarios, other scenarios including COLR v0 are also widely used in font icons. Color font is also a term used in CSS: https://drafts.csswg.org/css-fonts-4/#color-font-support
|
SVG fonts are pretty much an abandoned format in browsers (Chrome has never supported it and doesn't intend to), and COLRv1 is an alternative technology. I would suggest that consideration could be given to lowering the priority of this format implementation in resvg. |
Hi mates, amazing that you're working on it! |
Are you sure? At least on my Computer Chrome can handle emojis from Twitter Color Emoji, which as far as I know is an SVG font... But maybe it depends on the OS. But anyway, at least in my PR it wasn't much effort to support that, so it seems like the more "obscure" features of SVG fonts that deviate from standard SVG might not be used as commonly. So we might as well just add it.
AFAIK the new vesions for Noto Color Emoji use COLRv1 which currently isn't supported yet upstream. I don't know if there are any particular difficulties in implementing this or whether someone just needs to find some time to finish it, maybe @RazrFalcon can say more about that. But the older versions of Noto Color Emoji use bitmaps, which should work with that PR. |
See MDN SVG fonts:
You can try |
Oh. This is talking about the font element in SVG. Yes, this is deprecated, but I don't think there are any plans to implement this, anyway. I was talking about the SVG table in OpenType fonts, which use SVGs as glyph descriptions. And I think those are supported by web browsers. |
@yisibl The SVG Font element and TrueType's COLRv0 will be supported soon, thanks to @LaurenzV. COLRv1 is in progress by me harfbuzz/ttf-parser#133 (for a while now...). |
Sorry, I misremembered. Please ignore the MDN link and description. It's true that Chrome doesn't implement OT-SVG(See https://issues.chromium.org/issues/40336440), though, and it doesn't look like there are any plans to do so at the moment, since COLRv1 replaces OT-SVG with some extent. I don't have much of a problem with implementing OT-SVG in OT-SVG Test Page: https://pixelambacht.nl/lapislegit/ |
Fixed by #735 |
Emojis can be stored in multiple ways, but we should at least support bitmap one.
The text was updated successfully, but these errors were encountered: