[vitorsr]

To me, all of these crates reinvent the wheel when we have FreeType and HarfBuzz which are actually used in the real world.

I see no net gain in implementing or in using subpar nonreal-world-tested libraries just to do so in Rust.

[virtualritz]

How do you know something is sub-par if it is not tested? You can only make a statement about the former if the latter is true. But nice try.

[vitorsr]

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.

[1] https://gitlab.freedesktop.org/freetype/freetype/-/issues/?s...

[2] https://github.com/harfbuzz/harfbuzz/issues?q=is%3Aclosed

[laurmaedje]

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.

[vitorsr]

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.

[1] https://github.com/apple-oss-distributions/WebKit/tree/WebKi...

[2] https://github.com/apple-oss-distributions/WebKit/tree/WebKi...

[3] https://github.com/chromium/chromium/tree/main/third_party/f...

[4] https://github.com/chromium/chromium/tree/main/third_party/h...

[5] https://searchfox.org/mozilla-central/source/modules/freetyp...

[6] https://searchfox.org/mozilla-central/source/gfx/harfbuzz

[7] https://cs.android.com/android/platform/superproject/+/maste...

[8] https://cs.android.com/android/platform/superproject/+/maste...

[9] https://www.amazon.com/gp/help/customer/display.html?nodeId=...

[laurmaedje]

On the shaping side, support should be quite good as rustybuzz replicates harfbuzz results 1-1. (I think, it passes the whole test suite.) Regarding higher-level text layout: We have implemented BiDi, shaping, line breaking, reshaping, and font fallback to the best of our knowledge. (And I have been in the Harfbuzz and Chromium sources and bug trackers more than I can count while implementing it.) However, it's difficult to test as we can't catch many mistakes in the output that would be obvious to native speakers. This is something where we will need input from the community. Finally, there are also many specifics that we don't support yet like Kashida for Arabic or dictionary-based line breaking for Thai.

[virtualritz]

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.