Text rendering is one of those things that someone thinks they can get a basic version running in a week or so and 5 months later they're still trying to address rendering/memory/performance issues for a production quality renderer(or something on a constrained platform). So much of text is just implicit knowledge and it's amazing much our brains "skip over".
I've written two of them "from scratch" professionally with many supporting libraries and both times they were pretty serious undertakings.
Great post, not just about text layout/rendering but also the state of development for it, as pointed in the post for DirectWrite, Flutter (libtxt), Android, etc.
The outward links of resources in the post are also really invaluable.
Great article. Whenever you dive into internationalization things are far more complicated than you would expect (as is with almost every subject). The article does not mention that Arabic (and similar scripts) use kashida for text justification, which is a means of stretching certain characters/glyphs in the text, instead of 'stretching' white space. See: https://en.wikipedia.org/wiki/Kashida
Yeah, I didn't get much into justification, or that deeply into language-specific requirements. For Arabic, a good resource is https://www.w3.org/TR/alreq/ and it goes into considerable detail on kashida among other issues. Maybe I should add a block that has references to these documents, as they're a great resource.
It is of course still used and supported, because of Microsoft's deep commitment to backwards compatibility, but DirectWrite has been the recommended replacement since Windows 7 (and it was backported to Vista with Platform Update).
As this has been downvoted, perhaps it wasn't clear that I am being serious and earnest :)
I'm keenly interested in composing and talking to a loosely hierarchical structure of functions that do text layout through profunctor optics. Profunctor optics are an approach to define composable, hierarchical, and "simpler ways of writing programs that access the components of compound data structures". It's especially interesting when the problem context is this complex. To build that complex program, we would want to use the ways that are as simple as possible, right?
Can we use profunctor optics to build a functional (working) description of a text layout pipeline? Can we use profunctor optics to swap out components? (Probably!) Can we design a profunctor optic-based program structure that allows meaningful transformations of input and output as needed?
Abstract: Profunctor Optics Modular Data Accessors
Abstract Data accessors allow one to read and write components of a data structure, such as the fields of a record, the variants of a union, or the elements of a container. These data accessors are collectively known as optics; they are fundamental to programs that manipulate complex data. Individual data accessors for simple data structures are easy to write, for example as pairs of ‘getter’ and ‘setter’ methods. However, it is not obvious how to combine data accessors, in such a way that data accessors for a compound data structure are composed out of smaller data accessors for the parts of that structure. Generally, one has to write a sequence of statements or declarations that navigate step by step through the data structure, accessing one level at a time—which is to say, data accessors are traditionally not first-class citizens, combinable in their own right.
We present a framework for modular data access, in which individual data accessors for simple data structures may be freely combined to obtain more complex data accessors for compound data structures. Data accessors become first-class citizens. The framework is based around the notion of profunctors, a flexible gen- eralization of functions. The language features required are higher-order functions (‘lambdas’ or ‘closures’), parametrized types (‘generics’ or ‘abstract types’) of higher kind, and some mechanism for separating inter- faces from implementations (‘abstract classes’ or ‘modules’). We use Haskell as a vehicle in which to present our constructions, but other languages such as Scala that provide the necessary features should work just as well. We provide implementations of all our constructions, in the form of a literate program: the manuscript file for the paper is also the source code for the program, and the extracted code is available separately for evaluation. We also prove the essential properties, demonstrating that our profunctor-based representations are precisely equivalent to the more familiar concrete representations. Our results should pave the way to simpler ways of writing programs that access the components of compound data structures.
Text rendering is one of those things that someone thinks they can get a basic version running in a week or so and 5 months later they're still trying to address rendering/memory/performance issues for a production quality renderer(or something on a constrained platform). So much of text is just implicit knowledge and it's amazing much our brains "skip over".
I've written two of them "from scratch" professionally with many supporting libraries and both times they were pretty serious undertakings.