Bug when running workflow in real environment using PDF-lib

Ask us anything
1

Hello everyone.

I recently decided to use the PDF-lib library to generate some PDF in weweb.
Everything was working perfectly when testing my code using the test button inside of the workflow.

But when finally deciding to test the full workflow live on the form submit button, everything crumbled.
Explanation:

When calling the following:
const page = pdfDoc.addPage([600, 800]);

I will get this error:
“page must be of type n or PDFPage or Array, but was actually of type NaN”

What is so different about the the way javascript is run between when running using the test button, and running when actually clicking on the submit form button?

This is pretty critical, so I’d appreciate a quick response.

Thank you in advance

2

Can we see a screenshot from the logs? Are you sure it executes successfully when testing?

3

Hi Luka. Thank you for your response.
I got even better, I recorded a loom video of the issue.
You will see it’s very odd. Should there be any environment differences when running in test and when clicking on the submit button?

[Loom Message - 29 July 2024 | Loom](https://Video of the issue)

4

Hey Luka. Any update on that? Have you watched my loom video?
Cheers

5

I believe the issue is in the way you treat and embed images. Could you try handling and embedding the images like in this example?

      const pngUrl = 'https://pdf-lib.js.org/assets/minions_banana_alpha.png'
      const pngImageBytes = await fetch(pngUrl).then((res) => res.arrayBuffer())

      const pngImage = await pdfDoc.embedPng(pngImageBytes)
6

Thanks for your response Luka.

I have tried to replace with the code you provided, and I still get the error :frowning:

Actually, it doesn’t even matter what else I put in the code.

My code starts doing problem even if it’s just limited to the following:

const { PDFDocument, rgb, StandardFonts } = pluginVariables[/* pdf-lib */ '69d4a5bb-09a3-4f3d-a94e-667c21c057eb']['pdf-lib'];

const fontkit = pluginVariables[/* @pdf-lib/fontkit */ '69d4a5bb-09a3-4f3d-a94e-667c21c057eb']['@pdf-lib/fontkit'];

const pdfDoc = await PDFDocument.create();
pdfDoc.registerFontkit(fontkit);
const page = pdfDoc.addPage([600, 800]);

It’s failing on the last line and interprets [600, 800] as NaN

Again, as you can see the problem is not with the code. The problem is with weweb doing something different when the workflow is executing from the button click, and probably pointing to a different environment.

It would be great if you could tag in here someone who is experienced with your NPM integration, I think that this would help a lot.

Thank you

7

You can submit a bug on ticket on support.weweb.io with the link to this community thread and someone from the development team will take a look.

1 Like
8

Thanks Luka
I just created the ticket with steps to reproduce: WeWeb - Support
How much time approximately do you think it’s going to take?
Best

9

It depends a lot on the severity of the bug. I will follow up here once we know what kind of a bug it is

10

Thanks a lot! I’ve already received a pretty valuable response there, and it unblocked me on the first part of the issue. I have another issue with embedFont, it does the same problem. I will try to use the prebuilt stuff of PDF-lib as much as possible.

11

I made the whole flow work!

So for the addPage issue I just added PageSizes to the imports, then used PageSizes.A4 instead of [600,800] (Actually that’s cleaner)

Then I had the font issue.

For the font the problem was that I tried to pass an ArrayBuffer.
I transformed the ArrayBuffer to a base64 with

btoa(String.fromCharCode(...new Uint8Array(fontBytes))));

Then I add same issue with the image, but simply provided the base64 value to embedPng and it worked!

1 Like
12

Love to hear it, good luck in building

1 Like
13

Thanks Luka! Your help was crucial in resolving the case