all 61 comments

[–]pavelpotocek 82 points83 points  (10 children)

How is it so much faster than others? Does it rasterize with the same quality? Are there any tradeoffs that others did differently?

[–]domanite 99 points100 points  (4 children)

I'm curious how this can claim to be the fastest rasterizer in the world, when it has only been compared to other rust libraries.

[–]tinco 23 points24 points  (2 children)

Imagine the framerate of Dwarf Fortress on this puppy ;)

But seriously though, got a cool application in mind for this? Or just generally make everything faster?

[–]Nephophobic 23 points24 points  (1 child)

Love the name!

[–]KeavonGraphite 19 points20 points  (13 children)

I just want to say, thank you for tackling this. It's such a monolithic challenge but it is absolutely crucial, and relying on Harfbuzz and FreeType isn't a great long term solution for the Rust community.

Do you have any likely estimated timeline in mind for 1.0 and 2.0 releases?

[–]raphlinusdruid · piet · runebender 16 points17 points  (2 children)

This is awesome, and I'm glad to see it. I consider font-rs to be research, and for somebody to take it farther is success from a research perspective.

I would suggest keeping the scope of the fontdue crate itself focused on font rendering, and not try to take on shaping. Other crates can and should handle that. For one, you want to have shaping that works whether the glyphs are rendered with fontdue or on the GPU. Also, the boundary between shaping and higher level text layout is fuzzy, and different applications will have different requirements.

I'll say clearly now: skribo was an attempt to fill the need for a shaping crate, but only partially successful. There are a number of meta-problems with the project, but one of the biggest is no real integration with a higher level text layout API.

I'm very interested in seeing good solutions for these problems as well as for font rendering. But having a good solution for that is definitely a step in the right direction!

[–]razrfalconresvg 15 points16 points  (6 children)

Glad to see that more and more projects are using ttf-parser.

As someone, who is very interested in this area, I have some questions:

  1. Does the rasterization benchmark includes the font parsing itself?
  2. Do you have separate benchmarks for glyf and CFF?
  3. Do you have quality comparison with other libraries? Not the Rust one, obviously.
  4. What about (auto-)hinting and grid-fitting? ttf-parser doesn't support the gasp table, so I'm not sure how you processing it.
  5. What about variable fonts?
  6. What about emojis and other non-outline glyphs (bitmap, PNG, JPEG, SVG, COLR, etc)?
  7. Can I use the rasterization engine without the layout?

PS: I like that you've switched to ttf-parser just a week ago =)

[–]jonkoops 23 points24 points  (3 children)

I don't see a comparison with Pathfinder, have you run benchmarks against it?

[–]nickez2001 34 points35 points  (3 children)

Please don't reuse fontdue's raster code directly in your project. fontdue uses unsafe code in the rasterizer, and the rasterizer itself is very not safe to use on its own with un-sanitized input.

Do you have unsafe functions that aren't marked unsafe? That sounds like a "code smell". Otherwise this warning isn't really meaningful, every time you call an unsafe function you have to ensure that you live up to the documented expectations of that function.

[–]oleid 7 points8 points  (3 children)

Your library sounds great! Just wondering : what would be missing compared to standard font rendering on Linux via freetype

[–]cosina-ct1 4 points5 points  (4 children)

I'd love to try and help out with this during hacktoberfest! Are there any issues you think a newbie could help pick off? I imagine I'll need to start getting familiar with the code now to be of any use by October 😁

[–]levyb 3 points4 points  (3 children)

Will colored characters (ie, emoji) be supported to some degree by 2.0? I find support for things like emoji ligatures (for example, national flags like 🇬🇧) to be lacking, broadly. Namely the only places I've seen consistent support are in the libraries backing web browsers (which, ah, makes a degree of sense, since once of the color font formats is essentially embedded SVGs!)

[–]std-cin-get 3 points4 points  (2 children)

How does this compare to slug?

[–]SimonSapinservo 2 points3 points  (4 children)

Do any of the benchmarks include font parsing time? You write:


… which sounds like a potentially significant amount of work (and so time taken).

[–]jrmuizel 5 points6 points  (3 children)

Does it support subpixel antialiasing?

[–]zesterer 2 points3 points  (1 child)

Really excited to see this project maturing. I might have to start using it in more of my projects!

[–]capitol_ 2 points3 points  (2 children)

Since this contained a parser (for the font formats) and parsers can be tricky to implement I wrote a small fuzzing script and left it running overnight.

No crashes/findings at all, seems that there isn't any mistakes of that kind in this code :)

[–]xobs 1 point2 points  (2 children)

How efficient is it in terms of memory usage?

I'm looking for a way to render fonts in an embedded environment. Currently it's no_std, though I may add libstd to the bespoke operating system.

When I put together a dumb test for fontdue rusttype it used a lot less ram, however I fully expect that's because its doing something clever with memory mapped files.

Is that a usecase you're interested in or a direction you're considering?

[–]TheRealMasonMac 0 points1 point  (0 children)

Could this be used to create a PDF reader that can handle large files without choking?!

[–]IAmHereComrade 0 points1 point  (0 children)

Can you explain why it has rusttype as a dependency ? I am a noob trying to learn

[–]Plazmatic -3 points-2 points  (9 children)

So this is just a font rasterizer? And no GPU, SDF or vector gfx support tells me this isn't the fastest font renderer either. It sounds to me like this is the fastest legacy pixel wise font rasterizer on the CPU.