Prawn VS yoga

I'm a little confused by your comment. I've been using the Prawn library to generate PDFs on the backend for a side project I am working on for quite sometime https://github.com/prawnpdf/prawn

(Admittedly, the PDFs I generate are most certainly not beautiful, so maybe that's the difference)

to view the email preview (note the PDF attachment included in the email):  ## Prawn PDF [Prawn PDF](https://github.com/prawnpdf/prawn) is a pure Ruby PDF- generation library that comes packed with features, such as PNG and JPG image embeds, generated file encryption, right-to-left text rendering, a way to incorporate outlines for easy document navigation, and a lot more. Prawn comes with its own DSL, which drives its powerful PDF generation abilities. ### When to Use Prawn Although it's not a fully featured report generation library like the well-known [Jasper Reports](https://community.jaspersoft.com/), with a bit of work using it's powerful DSL, you can generate some really cool and rather complex PDF documents with Prawn. Even so, it's important to note that Prawn isn't everything. If you want to generate PDFs from HTML, then you should look elsewhere, as the gem provides very limited support for inline styling, something of a hurdle if you're working with rich HTML documents. ### Installing and Using Prawn To get started with Prawn, install it with this command: ```bash gem install prawn

Is the Prawn gem something you can utilize?

Prawn pdf: https://github.com/prawnpdf/prawn

Javascript isn't really my thing, so first I had a go with the Prawn library in ruby, but now I'm hacking LuaTex via Fennel and having a blast.

You have a few options when trying to create a PDF in a Rails environment. Prawn and Wicked PDF have been around for quite a while. I have been using both gems and they work fine. However, they have a few limitations that can make it difficult to handle more complex PDFs. I recently discovered Grover, which can remediate some of this inflexibility in creating PDFs.

On this note, Ruby’s Prawn is great at the writing half and I miss it in pretty much every other language.

are you using keynote to make the file and then export to pdf? I wonder if it could be possible to do this programatically, using ruby and prawn (https://github.com/prawnpdf/prawn) 🤔. I have zero time to try it today, but this could be a fun weekend project for sure.

We still wanted to leverage a layout engine that could be performant and easy-to-use. After doing some performance testing with native UIKit, Autolayout, and a few other third-party options, we ended up bringing FlexLayout into the mix, which is a Swift implementation of Facebook’s Yoga layout engine. All RPL components utilize FlexLayout in order to lay out content fast and efficiently. While we’ve enjoyed using it, we’ve found a few touch points to be mindful of. There are some rough edges we’ve found, such as utilizing stack views with subviews that use FlexLayout, that often come at odds with both UIKit and FlexLayout’s layout engines.

We have our own test suite (orginally derived from the test suite of Meta's Yoga layout library [0]) which consists of text fixtures that are small HTML snippets [1] and a test harness [2] that turns those into runnable tests, utilising headless chrome both to parse the HTML and to generate the assertions based on the layout that Chrome renders (so we are effectively comparing our implementation against Chrome). We currently have 686 generated tests (covering both Flexbox and CSS Grid).

We would like to utilise the Web Platform Test suite [3], however these are not in a standard format and many of the tests require JavaScript so we are not currently able to do that.

[0]: https://github.com/facebook/yoga

[1]: https://github.com/DioxusLabs/taffy/tree/main/test_fixtures

[2]: https://github.com/DioxusLabs/taffy/tree/main/scripts/gentes...

[3]: https://github.com/web-platform-tests/wpt/tree/master/css/cs...

The "engine" is built on top of amazing https://www.lwjgl.org/ and https://github.com/bkaradzic/bgfx/, and UI system is baked by https://github.com/memononen/nanovg and https://github.com/facebook/yoga

React Native uses the Yoga engine under the hood, which allows you to use CSS properties to layout your React Native UI in a way that translates really well. Layout in Yoga is limited to Flexbox and absolute/relative positioning, however; there is no CSS grid and no display attribute. This keeps things simpler and more performant, but if developers are accustomed to using other layout techniques on the web, they’ll need to adjust to this new limitation.

PR #246 is super interesting to check out: by fixing the caching strategy, we were able to eliminate an exponential time (with respect to tree depth) performance penalty, and get comparable speeds for flat and deeply nested layouts (something I'd never expected to be possible). Preliminary benchmarks shows us significantly faster than yoga, Meta's C++ library for the same thing, especially on deep trees. Not too shabby for a tiny team of volunteers!

You're going to build the CLI using Ink, a React component-based library for building interactive CLIs. It uses Yoga to build Flexbox layouts in the terminal, so most CSS-like props are available in Ink as well. Ink is simply a React renderer for the terminal, so all the React features are supported. No need to learn a new syntax specific to Ink.

Interesting.

I was thinking that this was going to be a crazy amount of layout engine work, but now I look a little closer it appears the layout work is farmed out to yoga [0] (not trying to take away anything from the effort here). So this project is almost a wrapper around running yoga as a renderer and using SVG as a form of backend target?

I say "appears" because the yoga landing page doesn't do a great job of explaining what it does.

[0] https://github.com/facebook/yoga