Open j-f1 opened 4 years ago
And it would be useful for apps that dynamically generate PDFs based on user input because they’d be able to render a preview in a fixed size box with SwiftUI or TokamakDOM then pass the same state to TokamakPDF
PDF is a pretty complex format, would rendering to HTML and then converting to PDF from that be a reasonable workaround in the meantime?
On iOS/macOS there's an API that allows rendering arbitrary UIView
/NSView
to a PDF, either of those could host a SwiftUI View
then. On other platforms something like html2pdf.js could work, and then wkhtmltopdf for a purely "headless" browser-less approach.
PDF is a pretty complex format, would rendering to HTML and then converting to PDF from that be a reasonable workaround in the meantime?
From my (limited) experience with making PDFs from HTML, the two formats are different enough that it can be hard to make things look good when converted to PDF. I think it might be worth doing it from scratch (maybe using a Swift library like TPPDF?) but this is definitely a low priority issue that can wait until the DOM tenderer is done.
On iOS/macOS there's an API that allows rendering arbitrary
UIView
/NSView
to a PDF, either of those could host a SwiftUIView
then. On other platforms something like html2pdf.js could work, and then wkhtmltopdf for a purely "headless" browser-less approach.
I am listening to Swift Talk by objc.io and they mention that creating PDFs from embedded SwiftUI views just generate embedded bitmaps in the PDF. They are reimplementing SwiftUI using a (vector based) CGContext in order to generate PDFs for this reason. And they uncover a lot of details about the layout and render processes while doing it.
It would be cool to have a way to render directly to a PDF, maybe with a limited set of views that match what people expect out of a PDF. This could be super useful for one-off page layouts for invitations and similar!