Despite the "Gold-suite" comparison, when looking at the KaTeX and RaTeX output [1], the KaTeX output is consistently better. RaTeX has either a lot of aliasing going on or appears blurry.
But the native and library nature of RaTeX is very interesting, especially with the provided C ABI.
If it's an open source project that has been used by others, please consider giving out maintainer access to others (now or later).
It's sad, when projects are abandoned and a whole bunch of users would be willing to (partially) maintain it, but the key holder implicitly or explicitly decided that nobody else should have access.
Forks are not he same: It's very hard to get enough traction with existing users and the discoverability is terrible.
As maintainer I won't be able to give you an unbiased response. The biggest difference is, that SFML is a C++ library.
What motivates me to work on SFML is, that we're building something separate from SDL. I don't think, we - as in the general developer world - do anyone a favor in consolidating everything into one library (why use X, when Y does the same?). Additionally, I think it's a very interesting "field" of trying to provide a common API across different OS; and sadly it seems to be an area where few resources exist and fewer developer actually understand it, as "everyone" just uses SDL. Finally, I really like the open and welcoming community we've built over the years and at the same time, I'm happy we're not getting as much attention/pressure as SDL.
Yeah, then again most people haven't experienced this and are happy to just enable "track changes" in Word and send the document back and forth, maybe if you're lucky, it's hosted on SharePoint or OneDrive.
OnlyOffice, Nextcloud OPffice, Collabora might all have free offerings to a degree, but you'll end up at the mercy of the companies behind those tools and OnlyOffice comes with Enterprise offering that does also cost money.
Costing money isn't necessarily bad, but it's also hard to beat free & libre.
The discussion requirement is often to prevent disappointment, waste of time, and anger, when maintainers simple close PRs, because it's not the direction they want the project to go. A lot of people will take this very personally, so it's much better to have a conversation about it beforehand.
A lot of users still like the mix of a good UI for most tasks, while being able to do a lot of power user stuff without an added layer. Plus many will choose macOS also for the hardware, which support for new chipsets is still rather WIP under Linux.
I hate this as well, especially since I have greylisting enabled on some email addresses, so by the time the email login is delivered, the login session has already timed out and of course the sender uses different mail servers everytime. So in some cases, it's nearly impossible to login and takes minutes...
In my opinion this is mostly self-inflicted by Microsoft.
Sure some push for web-based solution has moved a lot of people away from desktop applications, but even before that Microsoft muddied the waters of native UI development.
Moving from User32.dll and GDI to GPU based rendering with WPF, might not have been the worst idea - and WPF is still going strong - but it's a clear cut, leaving old apps un-upgradable. So if companies need to eventually rewrite it, will they stick with desktop apps or move to "web apps"?
Unfortunately, Microsoft didn't stop there, but we've since seen a bunch of different attempts at new Windows UI libs to the point, where nobody trusts Microsoft anymore (remember Silverlight?) and everyone else is left confused by the chaos of an ecosystem.
When you do a check on https://haveibeenpwned.com/Passwords nothing is sent to the server. Instead the password is hashed locally and a list of the hash range is downloaded, which contains all the hashes and the number of occurrences.
The server doesn't receive the password, neither in plain-text nor hash form.
But the native and library nature of RaTeX is very interesting, especially with the provided C ABI.
[1] https://ratex.lites.dev/demo/support-table