9 ms·

The program for it seems to be the one here https://typst.app/ https://typst.app/

• sitkack 4y ago
  Their supporting code is available on github and it is all in Rust. https://github.com/typst/ https://github.com/typst/
  • virtualritz 4y ago
    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? [1] https://gitlab.redox-os.org/redox-os/rusttype https://gitlab.redox-os.org/redox-os/rusttype [2] https://github.com/alexheretic/ab-glyph https://github.com/alexheretic/ab-glyph [3] https://github.com/mooman219/fontdue https://github.com/mooman219/fontdue [4] https://github.com/typst/pixglyph https://github.com/typst/pixglyph [5] https://github.com/raphlinus/font-rs https://github.com/raphlinus/font-rs
    • vitorsr 4y ago
      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 4y ago
        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 4y ago
          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/?state=closed https://gitlab.freedesktop.org/freetype/freetype/-/issues/?s... [2] https://github.com/harfbuzz/harfbuzz/issues?q=is%3Aclosed https://github.com/harfbuzz/harfbuzz/issues?q=is%3Aclosed
          • laurmaedje 4y ago
            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.