Comments
Wait, so the idea is in the future, fonts will contain arbitrary full-color vector and bitmap images, they will contain Web Assembly code that needs to be run, and they will be streamed over the network? I’m probably missing a few other proposals, as I only skimmed.
Did anyone stop to consider if this is really necessary? The author makes it sound like he has used his influence steadily over the years to make fonts more complicated. “In year X, I proposed that fonts be able to do Y, because why not?” I get that text shaping is so complex, that in terms of open source, there is just Harfbuzz. I’m not an expert in this area. But I don’t think it’s a good thing if “font standards” are constantly getting new features, like web standards, and font renderers are like mini browser engines, where the sheer scope and number of features and rate of new features keeps everyone using the same codebases.
By qingcharles 2024-07-1422:14 Well, we started this journey with bitmap fonts that wouldn't scale up, then most computers have been Western-oriented and didn't include full character sets for most of the people living on this planet. Then it turned out to be useful to be able to render languages and glyphs from dead ancient languages. And most languages other than English use all sorts of weird combining systems and accenting. When you type English it looks just like the keys you press. But type Arabic, especially with vowels, and it looks nothing like the keys you're hitting due to all the joining.
But the real kicker was emojis which threw a real spanner in the works. Prior to this text rendering had been universally mono, but we really had to add color then.
It's really about being inclusive. Writing (historically) was always something very analog, varying wildly between people, with all sorts of unbelievably arcane rules. Tech is just finally catching up with 5,000 years of history.
By sambazi 2024-07-109:59
> Moreover, the fontations platform, which is the Rust framework Oxidize is producing, will unify font compilation and consumption, reducing the number of places new font-format features need to be implemented from three (FontTools, FreeType, and HarfBuzz) to one (Fontations), which would reduce development cost and overhead.
Will FreeType and HarfBuzz remain supported as C/C++ projects long-term, I wonder? Asking as someone who depends on these and doesn't want to introduce a dependency on a Rust compiler :)
Anecdotally, I notice a lot of game developers avoid FreeType and Harfbuzz entirely, instead opting for much worse text rendering in the form of stb_truetype.h only (Dear Imgui uses this, for example) - which 'is nice because it is a single header C file' but sucks with international languages; many people use SDFs for similar reasons.
I think the proposed move to WASM fonts, if done right, could make it easier to reduce the amount of code people need to render fonts (if the WASM font does the heavy lifting, and a small C program could render it) and alleviate this trend of people not using a good text rendering stack
By chrchr 2024-07-0921:01 I wouldn't worry about it. I don't see evidence that these Rust libraries have the kind of uptake that is alleged in the article. I think we'll be stuck with Freetype and HarfBuzz for a long time.
I have been hacking on a Rust program recently and I am using Freetype and Harfbuzz via FFI because the Rust packages he names don't appear to be mature yet.
> doesn't want to introduce a dependency on a Rust compiler
you can link against pre-built .dll/.so/.dylib from your C++ code base.
By account42 2024-07-0914:59 That only helps you if all your targets are also actively supported by upstream. It also limits optimization opportunities, mainly removing parts of the library your code doesn't need.
I'm confused. When has a wasm interpret and small C program ever been the same thing?
By yencabulator 2024-07-1122:24 I think parent is saying the choice is between OpenType+large_C_library and font_WASM+small_library+generic_WASM_engine.
Interpreting OpenType is very complex.
By vanderZwan 2024-07-0915:101 reply > [It is ironic indeed, that a text about text rendering, is presented in such an inaccessible and badly-typed environment. This is a Google Docs Preview page. I am still yet to find a solution that provides the same features (collaboration, commenting, live edits) and is presented better. Suggestions are appreciated.]
Have you tried Observable? Their online notebook has live team editing built in, and the option to comment on cells, as well as fork and merge notebooks with suggested edits. However, it uses markdown instead of a WYSIWYG editor (although I did create some tagged template wrappers for djot and markdeep as possible alternatives). On the plus side it's really easy to write interactive demos!
They're kind of pivoting their product at the moment though, so I'm not sure how easy it is to get into the notebook part these days.
[0] https://observablehq.com/@jobleonard/djot
[1] https://observablehq.com/@jobleonard/wrapping-markdeep-into-...
Tangent, but I just found Observable. How are they pivoting their product?
By vanderZwan 2024-07-0920:05 Before they tried to build a business with their notebooks alone, but they recently released Observable Framework[0], which is "a static site generator for data apps, dashboards, reports, and more" that you can install and run offline via npm[1]. IIUC the business plan is to make money by hosting the generated sites on their website, and offering tight integration with their existing notebook tech to continue to let people edit those cooperatively.
I really hope they succeed because I'm a big fan of both Observable notebooks and the new Observable Framework (and their Observable Plot library is pretty good too. Really, they have tons of good stuff).
But basically, they now have two products, as mentioned in the "overview" section of their docs[2].
[0] https://observablehq.com/framework/
