If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.
Memory safety for web fonts
41–50 of 230 posts
Re: Memory safety for web fonts
#42Re: Memory safety for web fonts
#43If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.
Re: Memory safety for web fonts
#44FreeType is a dinosaur that should be replaced regardless of Rust or not.
Its age is completely irrelevant other than as demonstration that it did what it set out to do, and still performs that job as intended for people who actually work on, and with fonts.
Re: Memory safety for web fonts
#45It's very annoying that Google's websites, including this blog, are automatically translated to my browser's preferred language. Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it's far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at l…
Wouldn't the alternative be worse for most people? If you're a global company it would be silly to assume all your readers speak/read a single language. AI translations (assuming that's what this is) are not perfect, but better than nothing. I get how poor translation could be irritating for bilingual people who notice the quality difference though, but I guess you guys have the advantage of being able to switch the…
Re: Memory safety for web fonts
#46I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…
“Whole pixel/grayscale antialiasing” should be enough and then specialized display controller would handle the rest
Re: Memory safety for web fonts
#47I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…
Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.
Re: Memory safety for web fonts
#48If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.
The real issue is the effort required to rewrite everything without introducing new bugs resulting from a misunderstanding of the original code
Re: Memory safety for web fonts
#49Earlier quoted context omitted.
Hey, at least it's preferred language. It's much worse when it bases it on the country that I'm in, which I can only reasonably influence with a VPN, and calling that reasonable is a stretch.
This is the worst. I was in France recently and tons of mobile websites were just suddenly in French. It was a real chore to read through them, and I can only imagine how frustrating this is when you can't read the language put in front of you at all.
Re: Memory safety for web fonts
#50> Merely keeping up with the stream of issues found by fuzzing costs Google at least 0.25 full time software engineers I like this way of measuring extra work. Is this standard at Google?