My team rewrote Apple's TrueType hinting interpreter in Swift, ask me anything.
[…]
I feel like naming just one would be a disservices to all of the features that made this effort possible (C interop, generics, noncopyable/nonescapable types) but at the end of the day I think the star of the show was the optimizer; despite being faster than the code it replaced, the new code is super readable and that was only possible because the optimizer was able to completely eliminate all of our abstractions.
The new version is faster, but the main motivation was security concerns.
Is hinting useful/being used in the days of hi-dpi displays? I was under impression that Apple switched to grayscale anti-aliasing and ditched hinting.
For the most part hinting isn’t really necessary anymore, but thanks to being Turing-complete it has been Hyrum’s law-ed by at least one CJK font that uses hinting to lay out strokes in its characters.
There were three major TrueType implementations at Apple IIRC:
- The original 68K one
- A rewrite for Copland that lived with ATS/ATSUI after Copland was cancelled
- iPhone shipped one derived from heavily-modified FreeType that was current until today
One of the axioms for this project was that I wanted my team to write the most boring code possible—nearly identical structurally to the code it was replacing, because to do otherwise would introduce binary compatibility risk. The other axiom was 100% test coverage for all new code as it landed, with the same units testing both interpreters.
Is the font parsing code itself still C++?
There is also a “Safe Font Parser” for WebKit in Lockdown Mode, but it supports a subset of all the myriad features provided by font formats.
Previously:
Font Smoothing Interpreter iOS iOS 27 Mac macOS 27 Golden Gate Optimization Parser Programming Security Software Rewrite Swift Programming Language Typography
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。