Text rendering

[RazrFalcon]

Text rendering is not supported and not planned. This is an absurdly complex task and the Rust ecosystem doesn't provide basically any libraries to implement this.

We need:

• Font parser: ttf-parser.
• Text shaper: rustybuzz or all-sorts.
• Font database with a font fallback mechanism.
• High-quality glyph rasterization library. Like ab_glyph_rasterizer, but with FreeType level of quality.
• Code in tiny-skia that ties it all together.

[yisar]

I think woff2 is better than ttf.

[alerque]

@yisar WOFF2 is a file format organization and compression scheme to optimize transmission of fonts over the internet for embedding in websites. The font payload you get after transfer and decompression in the end is the same. These days whether packaged as TTF, OTF, or WOFF2 what you are getting in terms of shapes and font functionality is identical. And hence you need a TTF parser to handle WOFF2 ;-) And WOFF2 doesn't make much sense for local font rendering, it's more CPU time to optimize away something that isn't even a bottleneck when working with local font files.

[Brooooooklyn]

Maybe https://github.com/servo/font-kit is also suitable for tiny-skia, I've used it 3 years ago: https://github.com/rust-canvas/rust-canvas/blob/master/src/canvas/context_2d.rs#L226

[RazrFalcon]

@Brooooooklyn font-kit is a wrapper over system libraries, which is no go. I want a pure Rust solution.

[kettle11]

Take a look at ‘fontdue’ by @mooman219

It may meet your requirements: https://github.com/mooman219/fontdue

[RazrFalcon]

@kettle11 fontdue is just a rasterizer right now. We need a lot more.

[mooman219]

@kettle11 this is kinda a small rundown of my opinion of the situation

It may meet your requirements: https://github.com/mooman219/fontdue

Fontdue is a no-std raster and layout tool for non-shaped text over a small subset of font features found in glyphbrush/ab_glyph/rusttype. This feature subset we all support isn't freetype grade for reasons mentioned below. In terms of runtime performance, it's much faster than glyphbrush/ab_glyph/rusttype, all of which use the raster from font-rs. It does exact coverage anti aliasing just like font-rs, so the quality is the same.

This is an absurdly complex task and the Rust ecosystem doesn't provide basically any libraries to implement this.

This is fairly accurate. The problem is that overall, the crates mentioned above (no-std crates with nice APIs) in rust are very limited in their scope over the domains they cover. Freetype font engine grade text includes a whole slew of hard problems. A non exhaustive list of features we're generally missing include:

• Gzip decompression for woff if you really care about that
• RGB Subpixel anti aliasing/blending/positioning
• Font config (including fallback)
• Stem darkening
• Shaping to any degree
• Color emoji/color in general
• Variation axis transformations
• BiDi
• CJK locale behavior

The big one here is shaping, which in pure rust is immature and greatly influences the design of implementing some of these features like BiDi. Any serious work from any no-std font-engine can really start once that's settled in my opinion, so we're basically hoping that either rustybuzz or all-sorts mature. The rest of the features aren't nearly as insurmountable by comparison.

A quick note: Pathfinder actually does a ton of these things like stem darkening, RGB AA/Positioning, color emoji, and such, but I'm assuming that's out of the question given its kinda hard to integrate with and also on the gpu.

[mooman219]

I wanted to add linebreaking to that list as well. It's wildly more complex than the spec implies. The unicode linebreak annex defines the bare minimum you should handle, but is not freetype grade in the slightest. There's a ton of nuance and opinions in the space and across platforms that add/remove line break opportunities, handle trailing whitespace, etc.

This feels like making a working group territory, but also there's not a ton of people that actually care about pure rust solutions :'( . I think the xi zulip is the most concentrated group so far, but there's not a big push for no-std solutions there. I'd be happy to break anything out of fontdue / work on a small tool for one of these features if you see an opportunity. I really want to see great no-std rust text in the future.

[RazrFalcon]

@mooman219 Afaik, freetype does only rendering. It doesn't do layout in any way. At least on linux, it's up to pango/Qt.

Also, Skia has it's own paragraph implementation on top of harfbuzz. This what flutter use (or plan to use).

PS: Why do you care about no-std solutions?

[mooman219]

@mooman219 Afaik, freetype does only rendering. It doesn't do layout in any way. At least on linux, it's up to pango/Qt.

Whoops, I'm conflating pango in with freetype again for no good reason. s/pango/freetype where it matters in my original comment.

Also, Skia has it's own paragraph implementation on top of harfbuzz. This what flutter use (or plan to use).

Yep! I've read a lot about it the past few weeks which is why I wanted to mention linebreaking as a problem that still needs to be solved in pure rust, even if it's just cloned from Skia.

PS: Why do you care about no-std solutions?

This is mostly a personal opinion. I think that a huge benefit of having the ecosystem in pure rust is going the next step to being no-std. Fontdue for example is used in some no-std environments including a small kernel and on consoles, and there's really no reason to not be no-std for the majority of the stack as far as I can tell, unless you're aware of something significant? Font config / fallback behavior may be system dependent, but that can be optional. The only thing preventing allsorts from being nostd is that it depends on a std gzip library for woff.

[RazrFalcon]

no_std is kinda an abstract term. fontdue uses alloc, so it's not pure no_std in my opinion. ttf_parser is, because it doesn't use heap at all.

In this sense, tiny-skia also can be no_std, because the only thing from std I'm suing is Vec.

[mooman219]

No-std is a well defined term since it's a crate level attribute. I like to think alloc is in the spirit of no-std.

Alloc is reasonably free to add on most no-std environments. Requiring all the threading/networking/file system/etc components is really heavy. Making tiny-skia no-std and just needing alloc would be great for some of the common no-std environments like consoles

[bschwind]

I've been using fontdue for rasterization and basic layout, both in a work project and a personal project. I don't have any complicated text layout or shaping issues to handle, but I've been very pleased with the results so far. Someone with sharper eyes than mine may be able to spot issues, I'm somewhat of a layman when it comes to seeing slight issues with text rendering.