Add support for color fonts #735
Conversation
|
So I just tried adding support for SVG and the positioning seems to work out-of-the-box (for horizontal writing), so the issue definitely seems limited to bitmap emojis... |
|
Thanks, will take a look. |
|
COLRv0 works now, too! <svg id="svg1" viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg"
font-size="25">
<title>Emojis</title>
<path id="crosshair" d="M 20 100 L 180 100 M 100 20 L 100 180"
stroke="gray" stroke-width="0.5"/>
<text id="text1" x="0" y="50" font-family="Segoe UI Emoji">Hii😀 😁how </text>
<text id="text1" x="0" y="90" font-family="Twitter Color Emoji">Hii😀😁how </text>
<text id="text1" x="0" y="130" font-family="Apple Color Emoji">Hii😀😁how </text>
<text id="text1" x="0" y="160" font-family="Noto Color Emoji">Hii😀😁how </text>
<!-- image frame -->
<rect id="frame" x="1" y="1" width="198" height="198" fill="none" stroke="black"/>
</svg>Our output: Chrome: |
|
Here is a toy sbix font we can use to debug: https://github.com/simoncozens/test-fonts?tab=readme-ov-file#cff-and-sbixotf If I install it locally and open the following SVG: <svg id="svg1" viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg"
font-size="25">
<title>Emojis</title>
<path id="crosshair" d="M 20 100 L 180 100 M 100 20 L 100 180"
stroke="gray" stroke-width="0.5"/>
<text id="text1" x="0" y="100" font-family="CFF Outlines and SBIX">AAA</text>
<!-- image frame -->
<rect id="frame" x="1" y="1" width="198" height="198" fill="none" stroke="black"/>
</svg>I get the same behaviour on Firefox and Chrome. I'm trying to change different glyph metrics and recompile the font with EDIT: I tried changing different glyph metrics, and apart from x and y offset, none of them have any effect on the positioning... But in the original font the y offset is already 0, so that can't be where it is coming from. |
|
Thanks for looking into it. |
|
Looks like we are not the only ones troubled by this: harfbuzz/harfbuzz#2679 (comment) So can we ignore it for now? |
|
We should at least try to use the same hack everyone else is using. |
So Cool! Thank you for all you have done for this. |
Well, guess what: Consider the following SVG with the font I mentioned above: <svg id="svg1" viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg"
font-size="64">
<title>Emojis</title>
<path id="crosshair" d="M 20 100 L 180 100 M 100 20 L 100 180"
stroke="gray" stroke-width="0.5"/>
<text id="text1" x="0" y="100" font-family="CFF Outlines and SBIX">AAA</text>
<!-- image frame -->
<rect id="frame" x="1" y="1" width="198" height="198" fill="none" stroke="black"/>
</svg>Here is how it renders on MacOS in Chrome: Here is how it renders on Windows 11 in Chrome, which is exactly the same we have right now in So what I think is happening here is that Chrome, Firefox etc, use CoreText for rendering text in SVG, which is why on MacOS, they have the same behavior as all other Apple programs (like TextEdit, as mentioned in the issue linked above). However, on Windows they use something else, meaning that we don't have this same behaviour there... So I still think it's safe if we just ignore this for now, right? The reason why I'm reluctant to add manual corrections here is that right now, layouting doesn't care at all about which type of glyph is used, but if we want to add manual corrections, then we might have to decide on the type of glyph that is used while layouting, which is not so nice in my opinion. |
Sounds good to me. |
|
Regarding subsetting, I think I tried that but iirc fonttools didn't support subsetting SVG tables. But I will try again. So should I disregard TTB writing for now? |
Writing to SVG? Or do you mean the layout? It's fine. |
I remember that Alternatively, you can use nanoemoji to convert SVG files into color fonts in a variety of formats, which will produce test fonts that are small enough to use. |
Huh okay, I'll try it again then, thanks! |
|
I think I'm getting close now. I'll try to investigate the tb writing mode issue again, then clean up and then it should be ready. Hopefully will be done within the next few days. |
|
There's still something off, but not sure I will be able to fix it for now, this would require me to make a deep dive into how
versus in other browsers: 
For some reason there is more space in the vertical writing mode... But no idea why. I will add a test case regardless so we don't forget about it. |
|
I've added a few small TODOs where I wasn't sure what I should change it to. But otherwise it should be good, I hope. |
| transform: glyph.svg_transform(), | ||
| ..Group::empty() | ||
| }; | ||
| // TODO: Probably need to update abs_transform of children? |
There was a problem hiding this comment.
Yeah, I'm still thinking about a better abs_transform implementation. The current one is pretty meh.
| ..Group::empty() | ||
| }; | ||
| // TODO: Probably need to update abs_transform of children? | ||
| group.children.push(Node::Group(Box::new(tree.root))); |
There was a problem hiding this comment.
I'm not sure if we should keep it as Image::SVG. But I guess it can be changed later.
There was a problem hiding this comment.
Ah true... Yeah I guess both would work.
|
Thanks! Looks good to me. |
|
Ready to merge? |
|
I think so! |
Not polished code yet, but it should be enough to test it.
Oh, and top-to-bottom text also doesn't quite work yet. 😅