Feature requests/ideas

[HackbrettXXX]

First of all, I love that you're building a modern PDF library for JavaScript/TypeScript and like the approach so far. It looks very promising.

I'm wondering if you're planning to add more advanced drawing features, like:

• gradient or pattern fills
• reusable form-xobjects
• matrix transformations
• clip paths
• graphics state ("q" operator)

At a quick glance at the documentation I could not find them. Apologies if these features are already supported.

I'm a maintainer of svg2pdf and jsPDF. JsPDF is a bit outdated at this point and has become a nuisance to maintain with the very limited available resources. If LibPDF becomes successful, we might consider replacing svg2pdf's jspdf dependency with LibPDF and might even consider deprecating jspdf.

[Mythie]

Hey there, sounds great!

Most of the above is available externally so it's just a matter of exposing it externally.

I've got a branch with that as well as gradients, xobjects and matrix transformations that's almost ready.

It also gave me a neat idea for the near future.

[HackbrettXXX]

Great to hear! Looking forward to it.

[mehdi-taibi]

@Mythie Are you planning on implementing Office docs conversion to PDF?

[Mythie]

So I've exposed this under a low level/advanced API where you're interacting with operators.

https://libpdf.documenso.com/docs/advanced/low-level-drawing

If this is a bit too harsh let me know, I'm also planning a complementary package @libpdf/canvas that will provide a mostly Canvas compatible API for drawing on the PDF since this now exists.

[Mythie]

@Mythie Are you planning on implementing Office docs conversion to PDF?

Not any time soon, docx and such have a complex layout system and also don't embed the resources needed for printing. The LibreOffice SDK is the best way to deal with docx => pdf right now if you're looking for Open Source. Gotenberg provide this in a nice container format.

[HackbrettXXX]

So I've exposed this under a low level/advanced API where you're interacting with operators.

https://libpdf.documenso.com/docs/advanced/low-level-drawing

If this is a bit too harsh let me know, I'm also planning a complementary package @libpdf/canvas that will provide a mostly Canvas compatible API for drawing on the PDF since this now exists.

Looks great! I've some questions:

• Can I call drawOperators multiple times on a page?
• Can I add operations to a FormXObject after creation?
• Do gradients support transparency? I know that's not easy in PDF :D

[Mythie]

Can I call drawOperators multiple times on a page?

Sure can!

Can I add operations to a FormXObject after creation?

You can but this would be a bit more annoying since you'd end up doing something like xobject = pdf.ctx.resolve(ref); xobject.setData(serializeOperators(...))

Could be nicer for sure, any reason why you might not know the operators? I assume this is for <g> or <use>

Do gradients support transparency? I know that's not easy in PDF :D

I haven't done the soft masks for gradient transparency, I can probably make that happen as well.

Would you prefer doing this via raw PDF operators or via a canvas-esque backend?

I've got it mostly worked out as well, just a matter of slotting it in and deciding between complementary package or subpath export. @libpdf/canvas or @libpdf/core/canvas

[HackbrettXXX]

Could be nicer for sure, any reason why you might not know the operators? I assume this is for <g> or <use>

In jspdf there is always one "active" content stream that can be from a page or a form object. That makes it easy for svg2pdf to implement elements in defs used by <use>, because I can just set the the active content stream to the form object, then render the svg subtree (code distributed over many files) and then reset the content stream. But your approach would of course also work: we can write the ops to an array and eventually write it to a form object or a page.

I haven't done the soft masks for gradient transparency, I can probably make that happen as well.

Would you prefer doing this via raw PDF operators or via a canvas-esque backend?

Ideally, both.

I've got it mostly worked out as well, just a matter of slotting it in and deciding between complementary package or subpath export. @libpdf/canvas or @libpdf/core/canvas

No real preference here. Both variants have advantages. Maybe a slight tendency towards a separate package to keep the core API as lightweight as possible (PDF is already quite feature-rich).