14 ms·

Memory safety for web fonts

306 points by mmmrk 2y ago

waynecochran 2y ago
I get it, but switching to Rust places the codebase on an Island I can't easily get to. I am already switching between C++, Swift, Kotlin, and Python on an almost daily basis.
- sieabahlpark 2y ago
  [dead]
- cl0ckt0wer 2y ago
  just get the AI to understand it for you /s
  - waynecochran 2y ago
    It is not a matter of understanding source code. It is matter of bridging, building, and linking another language with yet another binary layout and interface.
    - int0x29 2y ago
      It's an extern c interface. That's not any different than dealing with a c library
      - waynecochran 2y ago
        That is good to know.
- bobajeff 2y ago
  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.
- MyOutfitIsVague 2y ago
  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( >
  - drott 2y ago
    We're using https://cxx.rs/ https://cxx.rs/ to create the bindings and FFI interface. That's not provided with Fontations, but this bit is part of the Chromium and Skia integration. The code is here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/src/ports/fontations/src/ffi.rs;l=1521 https://source.chromium.org/chromium/chromium/src/+/main:thi...
- deleted 2y ago
  [deleted]
- jsheard 2y ago
  Chromium is >35 million lines of code, switching languages all in one go just isn't happening.
- syklemil 2y ago
  You've already had some replies for the C FFI side of things, you might also be interested in maturin & PyO3 for python bindings. I haven't looked if they've exposed some python interface (guessing not), but Rust/Python interop is often pretty easy: https://www.maturin.rs/ https://www.maturin.rs/
tsuru 2y ago
It looks like there is an extern C interface... I wonder if it is everything necessary for someone to use it via FFI.
- steveklabnik 2y ago
  Given that it's being used in a large C++ codebase, I would assume it has everything needed to use it in that API.
- pornel 2y ago
  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)
declan_roberts 2y ago
> 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?
- whazor 2y ago
  I think this means the engineer fuzzes 4 projects?
  - colejohnson66 2y ago
    It means it costs them three months per year per employee. So, 'n' employees, n/4 years of man-power is spent fixing issues found by fuzzing. As others have said, FTE (full-time equivalent) is the more common name.
- adam_gyroscope 2y ago
  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.
- nairb774 2y ago
  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 $.
  - sanbor 2y ago
    I’m pretty sure FTE stands for full-time employee
    - jdlshore 2y ago
      When used to compare costs, “equivalent” is used instead of “employee.” “The cost of one full-time employee is equivalent to X CPUs.” —> “The full-time equivalent is X CPUs.”
Keyb0ardWarri0r 2y ago
This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.
- steveklabnik 2y ago
  > like Microsoft with its TypeScript rewrite in Go Go is also memory safe.
  - Keyb0ardWarri0r 2y ago
    But can't be embedded in other projects as easily as Rust (FFI, WASM).
    - steveklabnik 2y ago
      I don't disagree, but "not as easily" is different than "cannot be."
  - gpm 2y ago
    I'd argue technically not due to data races on interface values, maps, slices, and strings... but close enough for almost all purposes. PS. Note that unlike most languages, a datarace on something like an int in go isn't undefined behavior, just non-deterministic and discouraged.
    - steveklabnik 2y ago
      Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7 https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...
jasonthorsness 2y ago
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.
- cbdumas 2y ago
  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.
  - jasonthorsness 2y ago
    I sort of have this perspective, slowly changing… I think it comes from a fallacy of take a small 20-line function in C, it can be made bug-free and fully tested, a program is made of small functions, why can’t the whole thing be bug free? But somehow it doesn’t work like that in the real world.
    - graemep 2y ago
      There would be far fewer bugs if people actually stick to writing code like that. I once had to reverse engineer (extract the spec from the code) a C++ function that was hundreds of lines long. I have had to fix a Python function over a thousand lines long. I am sure the people who wrote that code will find ways to make life difficult with Rust too, but I cannot regret having one less sharp knife in their hands.
      - hombre_fatal 2y ago
        On the other hand, parceling a large function into smaller functions can create indirection that is even harder to follow and harder to verify as bug-free.
K0nserv 2y ago
I appreciate the pun in the repository name https://github.com/googlefonts/fontations/ https://github.com/googlefonts/fontations/
nine_k 2y ago
Look, a language that was conceived out of necessity to write a web browser in a safer way is being used just for that. It's a different, unrelated browser, but the language still reaches its design goals beautifully.
- deleted 2y ago
  [deleted]
SquareWheel 2y ago
I'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 exist to tweak how ClearType works, like MacType[1] or Better ClearType Tuner[2]. Unfortunately, these tools don't work in Chrome/electron, which seems to implement its own font rendering. Reading this, I guess that's through FreeType. I hope that as new panel technologies start becoming more prevalent, that somebody takes the initiative to help define a standard for communicating subpixel layouts from displays to the graphics layer, which text (or graphics) rendering engines can then make use of to improve type hinting. I do see some efforts in that area from Blur Busters[3] (the UFO Test guy), but still not much recognition from vendors. Note I'm still learning about this topic, so please let me know if I'm mistaken about any points here. [1] https://github.com/snowie2000/mactype https://github.com/snowie2000/mactype [2] https://github.com/bp2008/BetterClearTypeTuner https://github.com/bp2008/BetterClearTypeTuner [3] https://github.com/microsoft/PowerToys/issues/25595 https://github.com/microsoft/PowerToys/issues/25595
- cosmic_cheese 2y ago
  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.
- TheRealPomax 2y ago
  Mandatory reading when getting into this topic: http://rastertragedy.com/ http://rastertragedy.com/
fresh_broccoli 2y ago
It'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 least bilingual ones, got much worse.
- 3form 2y ago
  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.
  - ch4s3 2y ago
    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.
    - ryandrake 2y ago
      This is always infuriating, because browsers send the Accept-Language header, that these sites just ignore.
      - estebank 2y ago
        The thing I don't get is that there are plenty of Googlers traveling internationally. They've been aware of the problem for over a decade now, yet it persists. If I'm traveling from Spain to Poland with a browser set to use UK-English, why would the site immediately switch to Polish? It makes no sense that this common corner case isn't addressed at all after all this time. At the very least sites that do this should detect that there's a mismatch between expected language given geolocation and the header and have a toast notification about how to change the language settings back manually.
Ono-Sendai 2y ago
FreeType is a dinosaur that should be replaced regardless of Rust or not.
- TheRealPomax 2y ago
  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.
  - Ono-Sendai 2y ago
    I don't think you understand how backwards it is. My patch that makes SDF rendering 4x faster was not accepted, presumably because floating point-maths is some strange new-fangled technology. Freetype uses antiquated fixed-point integer maths everywhere. See https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/347 https://gitlab.freedesktop.org/freetype/freetype/-/merge_req...
    - TheRealPomax 2y ago
      I know how to read, and that MR comment sounds 100% reasonable to me. Normally you'd take a comment like that, go "oh, okay let me do some more investigations" and start a dialog instead of going "they rejected my MR on the first pass, they don't know what they're doing and their library is antiquated". Where's the follow-up, or did you just walk away?
      - TheRealPomax 2y ago
        Because to be a clear: a reviewer comment is the start of the conversation, if you don't respond then the bad actor is you, not them. Ask them why they don't want to use math.h, ask them if there are dev documents that explain what can and can't be used, and why. If you don't, this failure is on you, not them.
alberth 2y ago
[flagged]
- steveklabnik 2y ago
  Is anyone claiming that it is?
  - alberth 2y ago
    I didn't say anyone was claiming it was.
  - 9rx 2y ago
    If anyone was, how would it remain a feeling?
sidcool 2y ago
This is a wonderful write up. Reminiscent of the old google
- xyst 2y ago
  G engineering write ups are usually well written with plenty of useful information to carry forward. It’s G’s _business_ folks (ie, C-level executives) that I have no respect for. Their business model of exploiting users is just awful.
sam0x17 2y ago
TIL fonts have more than just a collection of vectorized glyphs in them
AndriyKunitsyn 2y ago
So, there's Skia. Skia is a high-level library that converts texts to glyph indices, does high-level text layout, and caches glyphs (and it also makes GPU calls). But the actual parsing of the font file and converting glyphs to bitmaps happens below in FreeType. Skia is made in C++. It's made by Google. There's FreeType. It actually measures and renders glyphs, simultaneously supporting various antialiasing modes, hinting, kerning, interpreting TrueType bytecode and other things. FreeType is made in C. It's not made by Google. Question: why was it FreeType that got a Rust rewrite first?
- interroboink 2y ago
  Perhaps since FreeType is the one handling the more untrusted inputs (the font files themselves, downloaded from who-knows-where), it is more at-risk and thus stood to benefit from the conversion more? But I don't really know anything about how all the parts fit together; just speculating.
  - londons_explore 2y ago
    Skia's inputs are relatively less complex, so there is less risk of dangerous corner cases.
- bawolff 2y ago
  Format parsing is generally considered some of the most risky type of code to have for memory safety. Skia is probably considered a less risky problem domain.
- raggi 2y ago
  It has a smaller API surface into the consuming applications and platforms. Skia tendrils run deep and leak all over the place. There's also a different set of work to invest in, next-generation Skia is likely to look quite different, moving much of the work on to the GPU, and this work is being researched and developed: https://github.com/linebender/vello https://github.com/linebender/vello. Some presentations about this work too: https://youtu.be/mmW_RbTyj8c https://youtu.be/mmW_RbTyj8c https://youtu.be/OvfNipIcRiQ https://youtu.be/OvfNipIcRiQ
jeffbee 2y ago
I wonder what this means, if anything, for the future of WUFFS. TTF support is on their roadmap. If they can get acceptable performance and safety from Rust, will they still drive on with WUFFS?
maxdamantus 2y ago
I hope that if we switch away from FreeType, we'll still have a way to use TTF hinting instructions fully. Windows/macOS don't seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it "subpixel hinting", which doesn't make sense to me in theory, and practically still seems blurry, as if it's unhinted). In case anyone's wondering what properly hinted text looks like, here's a screenshot [2]. This currently relies on setting the environment variable `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, possibly some other configuration through fontconfig, and using a font with good hinting instructions (eg, DejaVu Sans and DejaVu Sans Mono in the screenshot). My suspicion is that Windows moved away from font hinting after XP because it's very hard to create fonts with good sets of hinting instructions (aiui, OTF effectively only allows something like "autohinting"), so in the modern world of designer fonts it's easier to just have everyone look at blurry text. Some other minor reasons would be that UI scaling in Windows sometimes (or always?) introduces blurring anyway, and viewing raster images on screens of varying resolutions also introduces scaling blur. [0] Windows still has a way to enable it, but it disables antialiasing at the same time. This is using an option called "Smooth edges of screen fonts" in "Performance Options"). This basically makes it look like XP, which imo is an improvement, but not as good as FreeType which can do hinting and antialiasing at the same time. [1] https://freetype.org/freetype2/docs/hinting/subpixel-hinting.html https://freetype.org/freetype2/docs/hinting/subpixel-hinting... [2] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b299e8b1eaa524aab8e1bd/raw/313997632ad81ddd06f625ca02aa14ab244cf67f/hinted.png https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...
- nyanpasu64 2y ago
  > In addition, before the integration into Chromium, we ran a wide set of pixel comparisons in Skia, comparing FreeType rendering to Skrifa and Skia rendering to ensure the pixel differences are absolutely minimal, in all required rendering modes (across different antialiasing and hinting modes). I'm hoping (but not sure) Skrifa will support hinting (though I'm not sure how it interacts with fontconfig). I noticed your screenshot uses full hinting (a subjective choice I currently don't use on my machines), presumably with integer glyph positioning/advance which isn't scale-independent (neither is Windows GDI), though this is quite a nonstandard configuration IMO.
londons_explore 2y ago
This is the kind of work that Brave et al will never do.
codedokode 2y ago
> Fonts are passed through the OpenType Sanitizer prior to processing. Are font formats so bad that the files need to be sanitized? Also, note that the identified integer overflows as one of causes of vulnerabilities. It is sad that today many languages do not detect overflows, and even modern architectures like RISC-V do not include overflow traps although detecting an overflow doesn't require many logic gates. C is old, ok, but why new languages like Rust do not have overflow traps, I cannot understand. Don't Rust developers know about this thing?
- steveklabnik 2y ago
  Rust traps on overflow in debug mode, and does two’s compliment overflow in release mode. You can turn the traps on in release if you wish, but the cost is deemed too expensive to do so by default, especially when bounds are always checked, so it isn’t as severe of an issue in Rust.
  - codedokode 2y ago
    This becomes a vicious circle. Language developers do not want to make the language safer because legacy CPUs do not support overflow trapping, and CPU designers do not bother to add it because nobody needs it. For example, RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions.
    - snvzz 2y ago
      >RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions. It is not just "easy" to do, but actually easy to do, without quotes. And much, much easier than as an exception/trap. And it is explicit, which makes it even better. No hidden behaviour.
      - Joker_vD 2y ago
        What about execution speed? I find it somewhat hard to believe that adding 2/3 additional arithmetic instructions plus a branch to every addition/subtraction would perform better than having the (I believe quite small) circuitry after the ALU (probably still on the critical path) that detects carry-out/overflow and triggers a trap. > it is explicit, which makes it even better. No hidden behaviour. Which is why we do virtual address translation and populate (and evict!) L1/L2 caches in software, and the reason why CHERI project is misguided.
Am4TIfIsER0ppos 2y ago
You know what is even safer than all this? Not loading fonts from the web at all!
pyrolistical 2y ago
Why don’t they just port it to WASM? It provides an extra memory safety layer and it’s already in chrome

306 points by mmmrk 2y ago

I get it, but switching to Rust places the codebase on an Island I can't easily get to. I am already switching between C++, Swift, Kotlin, and Python on an almost daily basis.

sieabahlpark 2y ago
[dead]
cl0ckt0wer 2y ago
just get the AI to understand it for you /s
- waynecochran 2y ago
  It is not a matter of understanding source code. It is matter of bridging, building, and linking another language with yet another binary layout and interface.
  - int0x29 2y ago
    It's an extern c interface. That's not any different than dealing with a c library
    - waynecochran 2y ago
      That is good to know.
bobajeff 2y ago
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.
MyOutfitIsVague 2y ago
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( >
- drott 2y ago
  We're using https://cxx.rs/ https://cxx.rs/ to create the bindings and FFI interface. That's not provided with Fontations, but this bit is part of the Chromium and Skia integration. The code is here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/src/ports/fontations/src/ffi.rs;l=1521 https://source.chromium.org/chromium/chromium/src/+/main:thi...
deleted 2y ago
[deleted]
jsheard 2y ago
Chromium is >35 million lines of code, switching languages all in one go just isn't happening.
syklemil 2y ago
You've already had some replies for the C FFI side of things, you might also be interested in maturin & PyO3 for python bindings. I haven't looked if they've exposed some python interface (guessing not), but Rust/Python interop is often pretty easy: https://www.maturin.rs/ https://www.maturin.rs/

tsuru 2y ago

It looks like there is an extern C interface... I wonder if it is everything necessary for someone to use it via FFI.

steveklabnik 2y ago
Given that it's being used in a large C++ codebase, I would assume it has everything needed to use it in that API.
pornel 2y ago
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)

declan_roberts 2y ago

> 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?

whazor 2y ago
I think this means the engineer fuzzes 4 projects?
- colejohnson66 2y ago
  It means it costs them three months per year per employee. So, 'n' employees, n/4 years of man-power is spent fixing issues found by fuzzing. As others have said, FTE (full-time equivalent) is the more common name.
adam_gyroscope 2y ago
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.
nairb774 2y ago
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 $.
- sanbor 2y ago
  I’m pretty sure FTE stands for full-time employee
  - jdlshore 2y ago
    When used to compare costs, “equivalent” is used instead of “employee.” “The cost of one full-time employee is equivalent to X CPUs.” —> “The full-time equivalent is X CPUs.”

Keyb0ardWarri0r 2y ago

This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.

steveklabnik 2y ago
> like Microsoft with its TypeScript rewrite in Go Go is also memory safe.
- Keyb0ardWarri0r 2y ago
  But can't be embedded in other projects as easily as Rust (FFI, WASM).
  - steveklabnik 2y ago
    I don't disagree, but "not as easily" is different than "cannot be."
- gpm 2y ago
  I'd argue technically not due to data races on interface values, maps, slices, and strings... but close enough for almost all purposes. PS. Note that unlike most languages, a datarace on something like an int in go isn't undefined behavior, just non-deterministic and discouraged.
  - steveklabnik 2y ago
    Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7 https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...

jasonthorsness 2y ago

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.

cbdumas 2y ago
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.
- jasonthorsness 2y ago
  I sort of have this perspective, slowly changing… I think it comes from a fallacy of take a small 20-line function in C, it can be made bug-free and fully tested, a program is made of small functions, why can’t the whole thing be bug free? But somehow it doesn’t work like that in the real world.
  - graemep 2y ago
    There would be far fewer bugs if people actually stick to writing code like that. I once had to reverse engineer (extract the spec from the code) a C++ function that was hundreds of lines long. I have had to fix a Python function over a thousand lines long. I am sure the people who wrote that code will find ways to make life difficult with Rust too, but I cannot regret having one less sharp knife in their hands.
    - hombre_fatal 2y ago
      On the other hand, parceling a large function into smaller functions can create indirection that is even harder to follow and harder to verify as bug-free.

K0nserv 2y ago

I appreciate the pun in the repository name https://github.com/googlefonts/fontations/ https://github.com/googlefonts/fontations/

nine_k 2y ago

Look, a language that was conceived out of necessity to write a web browser in a safer way is being used just for that. It's a different, unrelated browser, but the language still reaches its design goals beautifully.

deleted 2y ago
[deleted]

SquareWheel 2y ago

I'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 exist to tweak how ClearType works, like MacType[1] or Better ClearType Tuner[2]. Unfortunately, these tools don't work in Chrome/electron, which seems to implement its own font rendering. Reading this, I guess that's through FreeType. I hope that as new panel technologies start becoming more prevalent, that somebody takes the initiative to help define a standard for communicating subpixel layouts from displays to the graphics layer, which text (or graphics) rendering engines can then make use of to improve type hinting. I do see some efforts in that area from Blur Busters[3] (the UFO Test guy), but still not much recognition from vendors. Note I'm still learning about this topic, so please let me know if I'm mistaken about any points here. [1] https://github.com/snowie2000/mactype https://github.com/snowie2000/mactype [2] https://github.com/bp2008/BetterClearTypeTuner https://github.com/bp2008/BetterClearTypeTuner [3] https://github.com/microsoft/PowerToys/issues/25595 https://github.com/microsoft/PowerToys/issues/25595

cosmic_cheese 2y ago
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.
TheRealPomax 2y ago
Mandatory reading when getting into this topic: http://rastertragedy.com/ http://rastertragedy.com/

fresh_broccoli 2y ago

It'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 least bilingual ones, got much worse.

3form 2y ago
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.
- ch4s3 2y ago
  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.
  - ryandrake 2y ago
    This is always infuriating, because browsers send the Accept-Language header, that these sites just ignore.
    - estebank 2y ago
      The thing I don't get is that there are plenty of Googlers traveling internationally. They've been aware of the problem for over a decade now, yet it persists. If I'm traveling from Spain to Poland with a browser set to use UK-English, why would the site immediately switch to Polish? It makes no sense that this common corner case isn't addressed at all after all this time. At the very least sites that do this should detect that there's a mismatch between expected language given geolocation and the header and have a toast notification about how to change the language settings back manually.

Ono-Sendai 2y ago

FreeType is a dinosaur that should be replaced regardless of Rust or not.

TheRealPomax 2y ago
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.
- Ono-Sendai 2y ago
  I don't think you understand how backwards it is. My patch that makes SDF rendering 4x faster was not accepted, presumably because floating point-maths is some strange new-fangled technology. Freetype uses antiquated fixed-point integer maths everywhere. See https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/347 https://gitlab.freedesktop.org/freetype/freetype/-/merge_req...
  - TheRealPomax 2y ago
    I know how to read, and that MR comment sounds 100% reasonable to me. Normally you'd take a comment like that, go "oh, okay let me do some more investigations" and start a dialog instead of going "they rejected my MR on the first pass, they don't know what they're doing and their library is antiquated". Where's the follow-up, or did you just walk away?
    - TheRealPomax 2y ago
      Because to be a clear: a reviewer comment is the start of the conversation, if you don't respond then the bad actor is you, not them. Ask them why they don't want to use math.h, ask them if there are dev documents that explain what can and can't be used, and why. If you don't, this failure is on you, not them.

alberth 2y ago

[flagged]

steveklabnik 2y ago
Is anyone claiming that it is?
- alberth 2y ago
  I didn't say anyone was claiming it was.
- 9rx 2y ago
  If anyone was, how would it remain a feeling?

sidcool 2y ago

This is a wonderful write up. Reminiscent of the old google

xyst 2y ago
G engineering write ups are usually well written with plenty of useful information to carry forward. It’s G’s _business_ folks (ie, C-level executives) that I have no respect for. Their business model of exploiting users is just awful.

sam0x17 2y ago

TIL fonts have more than just a collection of vectorized glyphs in them

AndriyKunitsyn 2y ago

So, there's Skia. Skia is a high-level library that converts texts to glyph indices, does high-level text layout, and caches glyphs (and it also makes GPU calls). But the actual parsing of the font file and converting glyphs to bitmaps happens below in FreeType. Skia is made in C++. It's made by Google. There's FreeType. It actually measures and renders glyphs, simultaneously supporting various antialiasing modes, hinting, kerning, interpreting TrueType bytecode and other things. FreeType is made in C. It's not made by Google. Question: why was it FreeType that got a Rust rewrite first?

interroboink 2y ago
Perhaps since FreeType is the one handling the more untrusted inputs (the font files themselves, downloaded from who-knows-where), it is more at-risk and thus stood to benefit from the conversion more? But I don't really know anything about how all the parts fit together; just speculating.
- londons_explore 2y ago
  Skia's inputs are relatively less complex, so there is less risk of dangerous corner cases.
bawolff 2y ago
Format parsing is generally considered some of the most risky type of code to have for memory safety. Skia is probably considered a less risky problem domain.
raggi 2y ago
It has a smaller API surface into the consuming applications and platforms. Skia tendrils run deep and leak all over the place. There's also a different set of work to invest in, next-generation Skia is likely to look quite different, moving much of the work on to the GPU, and this work is being researched and developed: https://github.com/linebender/vello https://github.com/linebender/vello. Some presentations about this work too: https://youtu.be/mmW_RbTyj8c https://youtu.be/mmW_RbTyj8c https://youtu.be/OvfNipIcRiQ https://youtu.be/OvfNipIcRiQ

jeffbee 2y ago

I wonder what this means, if anything, for the future of WUFFS. TTF support is on their roadmap. If they can get acceptable performance and safety from Rust, will they still drive on with WUFFS?

maxdamantus 2y ago

I hope that if we switch away from FreeType, we'll still have a way to use TTF hinting instructions fully. Windows/macOS don't seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it "subpixel hinting", which doesn't make sense to me in theory, and practically still seems blurry, as if it's unhinted). In case anyone's wondering what properly hinted text looks like, here's a screenshot [2]. This currently relies on setting the environment variable `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, possibly some other configuration through fontconfig, and using a font with good hinting instructions (eg, DejaVu Sans and DejaVu Sans Mono in the screenshot). My suspicion is that Windows moved away from font hinting after XP because it's very hard to create fonts with good sets of hinting instructions (aiui, OTF effectively only allows something like "autohinting"), so in the modern world of designer fonts it's easier to just have everyone look at blurry text. Some other minor reasons would be that UI scaling in Windows sometimes (or always?) introduces blurring anyway, and viewing raster images on screens of varying resolutions also introduces scaling blur. [0] Windows still has a way to enable it, but it disables antialiasing at the same time. This is using an option called "Smooth edges of screen fonts" in "Performance Options"). This basically makes it look like XP, which imo is an improvement, but not as good as FreeType which can do hinting and antialiasing at the same time. [1] https://freetype.org/freetype2/docs/hinting/subpixel-hinting.html https://freetype.org/freetype2/docs/hinting/subpixel-hinting... [2] https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b299e8b1eaa524aab8e1bd/raw/313997632ad81ddd06f625ca02aa14ab244cf67f/hinted.png https://gist.githubusercontent.com/Maxdamantus/3a58d8e764b29...

nyanpasu64 2y ago
> In addition, before the integration into Chromium, we ran a wide set of pixel comparisons in Skia, comparing FreeType rendering to Skrifa and Skia rendering to ensure the pixel differences are absolutely minimal, in all required rendering modes (across different antialiasing and hinting modes). I'm hoping (but not sure) Skrifa will support hinting (though I'm not sure how it interacts with fontconfig). I noticed your screenshot uses full hinting (a subjective choice I currently don't use on my machines), presumably with integer glyph positioning/advance which isn't scale-independent (neither is Windows GDI), though this is quite a nonstandard configuration IMO.

londons_explore 2y ago

This is the kind of work that Brave et al will never do.

codedokode 2y ago

> Fonts are passed through the OpenType Sanitizer prior to processing. Are font formats so bad that the files need to be sanitized? Also, note that the identified integer overflows as one of causes of vulnerabilities. It is sad that today many languages do not detect overflows, and even modern architectures like RISC-V do not include overflow traps although detecting an overflow doesn't require many logic gates. C is old, ok, but why new languages like Rust do not have overflow traps, I cannot understand. Don't Rust developers know about this thing?

steveklabnik 2y ago
Rust traps on overflow in debug mode, and does two’s compliment overflow in release mode. You can turn the traps on in release if you wish, but the cost is deemed too expensive to do so by default, especially when bounds are always checked, so it isn’t as severe of an issue in Rust.
- codedokode 2y ago
  This becomes a vicious circle. Language developers do not want to make the language safer because legacy CPUs do not support overflow trapping, and CPU designers do not bother to add it because nobody needs it. For example, RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions.
  - snvzz 2y ago
    >RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions. It is not just "easy" to do, but actually easy to do, without quotes. And much, much easier than as an exception/trap. And it is explicit, which makes it even better. No hidden behaviour.
    - Joker_vD 2y ago
      What about execution speed? I find it somewhat hard to believe that adding 2/3 additional arithmetic instructions plus a branch to every addition/subtraction would perform better than having the (I believe quite small) circuitry after the ALU (probably still on the critical path) that detects carry-out/overflow and triggers a trap. > it is explicit, which makes it even better. No hidden behaviour. Which is why we do virtual address translation and populate (and evict!) L1/L2 caches in software, and the reason why CHERI project is misguided.

Am4TIfIsER0ppos 2y ago

You know what is even safer than all this? Not loading fonts from the web at all!

pyrolistical 2y ago

Why don’t they just port it to WASM? It provides an extra memory safety layer and it’s already in chrome