Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of Text Rendering 2024

behdad.org

Post reply on HN
Print view View original

71–77 of 77 posts

Re: State of Text Rendering 2024

#71

Post by nineteen999 »

wokwokwok wrote: post #7

This is a lovely write up, but oh boy... when I see: > Finally, I proposed that the future of font shaping and drawing/ painting will involve a fully-programmable paradigm. > Two tongue-in-cheek mis-uses of the HarfBuzz Wasm shaper appeared recently: the Bad Apple font, and llama.ttf. Check them out! See... the thing about solving problems is that, eventually you realize that any kind of problem can be solved by simp…

What else are we supposed to do with all these massively multicore CPU's and gigabytes of RAM?

Re: State of Text Rendering 2024

#72

Post by sambazi »

dgreensp wrote: post #59

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 m…

https://fuglede.github.io/llama.ttf/

Re: State of Text Rendering 2024

#73

Post by eviks »

techn00 wrote: post #30

To everybody complaining about the awful text rendering, it's literally in the first paragraph > [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.]

Why do you need those features for a published long document? Do the editing and collaboration in an ugly platform, but publish in something more readable?

Re: State of Text Rendering 2024

#74

Post by funcDropShadow »

wokwokwok wrote: post #7

This is a lovely write up, but oh boy... when I see: > Finally, I proposed that the future of font shaping and drawing/ painting will involve a fully-programmable paradigm. > Two tongue-in-cheek mis-uses of the HarfBuzz Wasm shaper appeared recently: the Bad Apple font, and llama.ttf. Check them out! See... the thing about solving problems is that, eventually you realize that any kind of problem can be solved by simp…

You are missing the point. Finally, it'll be possible to exploit side-channel attacks without using Javascript in the browser. Static HTML+CSS+Fonts websites won't be safe anymore. Yippieee! Finally, there is no reason to allow disabling Javascript anymore.

And you could add backdoors to hacked fonts that are activated by magic spells. Isn't it great.

Re: State of Text Rendering 2024

#75

Post by yencabulator »

jpc0 wrote: post #64
slimsag wrote: post #22

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

I'm confused. When has a wasm interpret and small C program ever been the same thing?

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.

Re: State of Text Rendering 2024

#76

Post by FreeFull »

heftig wrote: post #5

I'm not sure how this gets rendered, but the lack of hinting makes it a strain to read. What irony that an article about progress in text rendering has such awful rendering quality. PS: That is in Firefox. In Chrome it uses what appears to be a bitmap font, which is much worse.

If you click the Google Docs link at the top of the document, you can then export it to html/txt/pdf.

Re: State of Text Rendering 2024

#77

Post by qingcharles »

dgreensp wrote: post #59

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 m…

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.

Post reply on HN