Update gnome bindings and librsvg #78
Conversation
calebcartwright
force-pushed
the
bump
branch
4 times, most recently
from
e5c39d6 to
4981573
Compare
This comment was marked as outdated.
This comment was marked as outdated.
calebcartwright
changed the title
|
I checked this out locally. Core of it all seems to work fine. As always.. emojis fonts seem to be the pain point. They seem to have all gone feint/monochrome main
PR #78
etc |
|
Good shout, I really should've thought to check given the system level nature of the changes. Very much looking forward to getting review apps together and hopefully #35 one day too. I suspect the change may be deliberate, based on https://developers.googleblog.com/2022/04/what-is-black-and-white-and-read-all.html (probably related to some font priority/selection changes) what are your thoughts? |
|
Its always emoji 😄 I actually saw that same article the other day. My assumption is that what we're seeing here is actually not that font. Have a look at the section of the article with the subheading "New designs, fewer details" (sorry - it doesn't have an anchor I can deep-link to) and then compare to:
Aside from that, if possible I think we should try to see if we can find a solution that uses the same emoji set we're working with for now for 2 reasons:
I'm happy to try and have a look at that when I get a chance. |
As in, within the execution runtime the noto fonts aren't being used for the emoji? That would surprise me if so, but should be a relatively easy hypothesis to test (will do so later if you don't beat me to it)
I'm not sure I follow. When you say "set we're using now" what's that in reference to? If it's the svgs then I'm not sure how practical that is going to be given that for svgs that will vary (or at least can vary) from platform to platform and browser to browser. For example on my machine (Ubuntu 22.04 in Firefox) the font used for the emoji in the SVG is I'm also not sure if you'd made an inference from my last comment, but to be unequivocally clear, I think this is a problem we need to do something about/I don't think we should proceed as-is with this current state of emoji. However, my first assumption was somehow that the |
Sorry. I mean we should try to retain the font that squint is using in production today ("noto emoji color"?) e.g:
(if possible).
I think the font that is being described in https://developers.googleblog.com/2022/04/what-is-black-and-white-and-read-all.html isn't the one we're seeing on the badges generated by the code on this branch. If you compare the flags from the section titled "New designs, fewer details" in that article to
What we're seeing is the exact design decision they're saying they didn't take. |
|
Gotcha, thanks for the clarification! I did a quick spot check in the container to ensure the font package was installed correctly and recognized, but also agree with you that it doesn't seem to be getting used. We probably just need to find the right incantations to chuck into the dockerfile to address that 🤞 |
|
Hmm. I'm stumped on this. Tried various overrides in Rolled back all of that. Fundamentally, Noto Emoji Color is installed. If I run so that should be the font being used. I think based on that maybe whatever is causing it not to use Noto Color Emoji is the changes at the rust lib layer rather than the changes at the OS layer. |
I had a similar thought and tried exploring this as well. One of the things I attempted (based on a thread in one of those upstream issues) was to include the noto reference in the font family list within the svg, but that didn't make any difference either 🤷♂️ |
|
Confirmed that it's related to the lib updates. Updated the OS in the Docker image to the latest, while sticking with the same libs (outside updating to openssl 3) and the emoji are still the same |
|
I'm still not having any luck trying to force the cairo context to use a certain font (the API has such a function, but it doesn't fix the issue). However, I did notice a couple upstream bugs/PRs that were highly font related so probably going to shift back to a wait-with-:crossed_fingers: strategy for the time being |
|
I think it will be easier to start fresh rather than trying to resolve the conflicts. I'll cherry-pick any relevant commits next time I have another go at this |
|
If we come back to this, hopefully the image diff tests will make it easier to quickly tell if we've got it right or not 🤞 |
Best summarized in this comment, but the tl;dr version is that we've been blocked on updating this batch of dependencies for a few months due to one of them (librsvg) increasing the minimum supported version of a system package (pango).
This PR bumps the platform version of our Docker image (and CI) to the newly released Ubuntu 22.04, the latest LTS version. That includes a supported version of pango out of the box (which wasn't readily available in the prior LTS version) which resolved the system package issues referenced in the prior PR.
Will also note taht the update to 22.04 required some minor surgery on the lockfile to account for the upgrade from OpenSSL v1.1.1 to v3.x (a forced update of
once_cellwhich was required to force updatenative-tlswhich was required to force updateopenssl&openssl-systo versions that can operate with OpenSSL v3.x).This gets things back in good working order and able to update these dependencies again going forward. This does transitively carry forward some system requirements for us, though in my opinion they are quite reasonable: >= Ubuntu 21.10/Ubuntu 22.04 (LTS), >= Debian 11 (Bullseye), >= Fedora 34, etc., especially since people can always use the Docker process from any environment even if they're on older systems. The minimum supported version of pango has been available on Mac (via homebrew) for quite a long time already, and the Windows story remains centered around WSL where users have all sorts of distro flexibility.