So for sub-pixel accurate font rasterization in Rust there are [1], [2], [3] and now the one from Typist, [4]. Possibly there are more (I know Raph Linus stopped maintaining [5] so that one is out).
All of these crates are actively maintained. Are people re-inventing the wheel?
The linked libraries are not even close to solving limited subsets of problems solved by FreeType or HarfBuzz. No test is needed if they do not even have a working implementation of particular requisites: Do they work on heterogeneous layouts, directions, languages, locales, scripts, symbols and composites, extensions, variations, legacy, missing, partial or corrupted instructions, standards interpretations, platforms, output devices, nonstandard point structures and grids?
They do not. What they solve is almost a toy problem compared to the size, scope and breadth of these libraries.
Just because some project is implemented in Rust does not make it comparable never mind superior by default.
There is a world out there and it is not homogeneous format and standards-compliant Latin fonts in English LTR text in linear disposition with some generic rectangular subpixel rendering on a regular rectangular grid.
I warmly welcome you to browse closed issues of FreeType [1] and also the closed issues of HarfBuzz [2]. If you feel inspired please do also look into mailing lists and discussion pages related to the development, building, tracking and patching of packages of these projects in any of the numerous places it is used.
The only argument Rust people have is in relation WASM but if you insist in targeting WASM why not fork FreeType, strip it to the strict subset of features your application needs and target it?
Why do it in the first place? Why reinvent the wheel?
As such I will restate my view: I see no gain in using any of these subpar libraries.
I would argue that font rendering and text shaping are completely separate problems. The font renderer doesn't need to know about directions, language, locales and scripts and using one of these simple libraries doesn't mean that an application cannot have a capable text layout and shaping implementation.
Although Typst uses pixglyph for rendering, it does support BiDi, complex script shaping, etc. For shaping, we use rustybuzz, which is pretty much a 1-1 port of harfbuzz to Rust. Although we would have gladly used harfbuzz, linking C and Rust in WASM is unfortunately not really possible. So we went for the practical choice of helping finish this port and using it.
Thanks. Yes, rendering and shaping are distinct but some of the linked libraries did one, the other, or both and the parent commenter singled out rastering which is how I ended up putting FreeType and HarfBuzz in the same sentence. Even then both are commonly used in tandem (see [1]-[9]) and have a few overlapping functionalities.
> it does support BiDi, complex script shaping
Hey, that is indeed quite good. Would you mind if I ask you how well is the support for popular Asian languages?
> linking C and Rust in WASM is unfortunately not really possible
Damn. I am not very experienced in Rust but I would not have guessed that. I apologize if I misrepresented difficulties related to targeting WASM.
I'm sorry but I can't help but conclude that you decided to bring in text shaping to have a reason for your counterpoint to be valid after my last reply.
As someone who studied typography and worked in that field professionally I understand the complexity of these subjects.
If you re-read my question it was about rasterisers. I.e. something that takes a bunch of lines, quadrics and cubics and draws a filled shape.
Everything else you read between the lines of my question but it wasn't there.
All of these crates are actively maintained. Are people re-inventing the wheel?
[1] https://gitlab.redox-os.org/redox-os/rusttype
[2] https://github.com/alexheretic/ab-glyph
[3] https://github.com/mooman219/fontdue
[4] https://github.com/typst/pixglyph
[5] https://github.com/raphlinus/font-rs