Memory Safety for Web Fonts

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout.

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.

The standard is EDID-DDDB, and subpixel layout is a major part of that specification. However I believe display manufacturers are dropping the ball here.

https://glenwing.github.io/docs/VESA-EEDID-DDDB-1.pdf

For me, being old time user, (ab)using any subpixel layouts for text rendering and antialiasing is counterproductive and (especially with current pixel densities, but also in general) introduces much more issues that it actually ever solved

“Whole pixel/grayscale antialiasing” should be enough and then specialized display controller would handle the rest

Sub-pixel anti-aliasing requires outputing a pixel-perfect image to the screen, which is a challenge when you're also doing rendering on the GPU. You generally can't rely on any non-trivial part of the standard 3D-rendering pipeline (except for simple blitting/compositing) and have to use the GPU's compute stack instead to address those requirements. This adds quite a bit of complexity.

Windows has always allowed you to change subpixel layout, its right there in the clear type settings.

I may be totally off the mark here, but my understanding is that the alternative pixel arrangements found in current WOLED and QD-OLED monitors are suboptimal in various ways (despite the otherwise excellent qualities of these displays) and so panel manufacturers are working towards OLED panels built with traditional RGB subpixel arrangements that don’t forfeit the benefits of current WOLED and QD-OLED tech.

That being the case, it may end up being that in the near future, alternative arrangements end up being abandoned and become one of the many quirky “stepping stone” technologies that litter display technology history. While it’s still a good idea to support them better in software, that might put into context why there hasn’t been more efforts put into doing so.

Mandatory reading when getting into this topic: http://rastertragedy.com/

Yes, a SWE-year is a common unit of cost.

And there are internal calculators that tell you how much CPU, memory, network etc a SWE-year gets you. Same for other internal units, like the cost of a particular DB.

This allows you to make time/resource tradeoffs. Spending half an engineer’s year to save 0.5 SWE-y of CPU is not a great ROI. But if you get 10 SWE out of it, it’s probably a great idea.

I personally have used it to argue that we shouldn’t spend 2 weeks of engineering time to save a TB of DB disk space. The cost of the disk comes to less than a SWE-hour per year!

FTE. Full time equivalent. Mosts costs are denominated in FTE - headcount as well as things like CPU/memory/storage/...

The main economic unit for most engineers is FTE not $.

Yeap, kinds of. It's preferred because whenever you propose/evaluate some changes, you can have a rough idea whether it was worth the time. Like you worked on some significant optimization then measure it and justify like the saving was 10 SWE-years where you just put 1 SWE-quarter.

Yes, all those well paid C-level managers cannot handle multiple units so they require everyone to use one “easy to understand unit so that everything is easy to compare and micromanage”

Yep, often things are measured in FTE or FTE-equivalent units. It’s not precise of course but is a reasonable shorthand for the amount of work required.

I think this means the engineer fuzzes 4 projects?

> like Microsoft with its TypeScript rewrite in Go

My understanding is that Microsoft chose Go precisely to avoid having to do a full rewrite. Of all the “modern” native/AoT compiled languages (Rust, Swift, Go, Zig) Go has the most straightforward 1:1 mapping in semantics with the original TypeScript/JavaScript, so that a tool-assisted translation of the whole codebase is feasible with bug-for-bug compatibility, and minimal support/utility code.

It would be of course _possible_ to port/translate it to any language (Including Rust) but you would essentially end up implementing a small JavaScript runtime and GC, with none or very little of the safety guarantees provided by Rust. (Rust's ownership model generally favors drastically different architectures.)

In a similar way Rust can be very useful for the hot path in programs written in Python, Ruby, etc. You don't have to throw out and rewrite everything, but because Rust can look like C you can use it easily anywhere C FFI is supported.

> like Microsoft with its TypeScript rewrite in Go

Go is also memory safe.

Given that it's being used in a large C++ codebase, I would assume it has everything needed to use it in that API.

They just need to rewrite the rest of Chrome to use the native Rust<>Rust interface.

(in reality Google is investing a lot of effort into automating the FFI layer to make it safer and less tedious)

Despite mounting evidence this perspective remains shockingly common. There seems to be some effect where one might convince oneself that while others are constantly introducing high severity bugs related to memory un-safety, I always follow best practices and use good tooling so I don't have that issue. Of course evidence continues to build that no tooling or coding practice eliminates the risk here. I think what's going on is that as a programmer I can't truly be aware of how often I write bugs, because if I was I wouldn't write them in the first place.

FreeType was written when fonts were local, trusted, resources, and it was written in low-level C to be fast. The TrueType/OpenType format is also made for fast access, e.g. with internal pointers, making validation a pain.

So though FreeType is carefully written w.r.t. correctness, it was not meant to deal with malicious input and that robustness is hard to put in afterwards.

That perspective is blown to those that see beyond themselves.

Or can admit themselves as fallible.

Or realize that even if they are near-infallible, that unless they've studied the C _and_ C++ standards to the finest detail they will probably unintentionally produce code at some point that the modern C++ compilers will manage to make vulnerable in the name of undefined behaviors optimizations (see the recent HN article about how modern C/C++ compilers has a tendency to turn fixed-time multiplications into variable time and vulnerable to timing attacks).

But of course, there is always tons of people that believe that they are better than the "average schmuck" and never produce vulnerable code.

Is the FreeType2 test suite public? It looks like the project's tests/ directory only contains a script for downloading a single font [1]. They have a fuzz test repo with what appears to be a corpus of only a few hundred tests [2]. For critical infrastructure, like FreeType, I'd expect hundreds of thousands if not millions of tests, just like SQLite [3].

[1] https://gitlab.freedesktop.org/freetype/freetype/

[2] https://github.com/freetype/freetype2-testing/

[3] https://www.sqlite.org/testing.html

Better comparison would be fresh code in Rust vs fresh code in C. Re-writing in both languages following best practices testing and fuzzing. A big difference vs comparing to legacy C code that is trying to be maintained by throwing 0.25 google engineers at it to fix an ongoing stream of fuzzing issues.

There are no major blows required. The idea that carefully written C/C++ code is just as safe was never tenable in the first place, and obviously so.

freetype code looks chaotic, though, it was written for local trusted fonts first. It was a typical google move "let's expose this random thing to internet, we can add security in 2025".

The real issue is the effort required to rewrite everything without introducing new bugs resulting from a misunderstanding of the original code

The worst offender to me is Google Maps. I'm a native Spanish speaker but set my phone to English because I hate app translations. The problem is when I want to read reviews it automatically translates them from Spanish (my native language) to English. It doesn't make any sense!

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.

It would be nice to have a browser setting that says: Use the original version of the text, if it is written in one of my preferred languages.

I keep setting all my preferences *everywhere* to English, yet 50% of the time google search results are 100% Finnish. With a helpful "change to English" link that does not work.

Worst still Google Maps will insist on only showing street names, area names, an directions in Swedish.

Strong agree. I had worked at Google for four years before discovering that the API documentation I meticulously wrote was machine translated to other languages. Only by perusing these translations did I realize some API concepts had been translated; I had to overuse the backtick notation for code to suppress these translations.

This is not a just Silicon Valley problem though; Redmond had similar issues if you just use the newer parts of Windows in a non-English language.

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 language.

Translation technology has gotten so much better in the meanwhile, I didn't even notice it at first.

Was this a codebase you were working with regularly already? This project exposes a C FFI, so unless you were already working in the guts here, I don't think this should affect you terribly.

edit: I'm actually not seeing the C FFI, looking at the library. It must be there somewhere, because it's being used from a C++ codebase. Can somebody point to the extern C use? I'm finding this inside that `fontations` repository:

  > rg 'extern "'
  fontations/fauntlet/src/font/freetype.rs
  161:extern "C" fn ft_move_to(to: *const FT_Vector, user: *mut c_void) -> c_int {
  168:extern "C" fn ft_line_to(to: *const FT_Vector, user: *mut c_void) -> c_int {
  175:extern "C" fn ft_conic_to(
  187:extern "C" fn ft_cubic_to(
  >

Chromium is >35 million lines of code, switching languages all in one go just isn't happening.

For me it was already hard to get into chromium's code base. It takes too long to build and there's just so much to understand about it before you can make changes.

It might help if there was some way to play around with the APIs without having to wait so long for it to build. But as far as i know that's not currently possible.

[dead]

just get the AI to understand it for you /s

Is anyone claiming that it is?

It already is replaced by HarfBuzz https://harfbuzz.github.io

The best libraries are libraries that have a clearly defined goal, hit that goal, and then don't change until the goalposts get moved. Something that happens only very slowly in font land.

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.