Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed .yml build error caused by ternary in script name for e2e-node #2690

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

joelybahh
Copy link
Contributor

Screenshot 2024-03-27 at 11 20 19 am
In response to the above error, which seems to have been triggered after my recent PR merge, I removed the ternary from the name. At a glance, this appears to be for vanity purposes anyway.

Copy link

changeset-bot bot commented Mar 27, 2024

🦋 Changeset detected

Latest commit: cb53e4e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages
Name Type
@react-pdf/pdfkit Patch
@react-pdf/layout Patch
@react-pdf/renderer Patch
@react-pdf/svgkit Patch
@react-pdf/examples Patch
@react-pdf/e2e-node-cjs Patch
@react-pdf/e2e-node-esm Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@joelybahh
Copy link
Contributor Author

I thought this was a simple change because of small syntax error, looks like a can of worms I wasn't ready for 😅

@joelybahh
Copy link
Contributor Author

Could the E2E tests output be different now that this.bits is correctly being set?

@ranma42
Copy link

ranma42 commented Mar 30, 2024

Could the E2E tests output be different now that this.bits is correctly being set?

That does not seem to be the cause, as there are no images involved in the test.
Additionally, in my environment the same diff is also detected running the tests on 6ffd1b9 (right before the JPEG change). The very same issue seems to be even present since the very beginning of the e2e tests 021c354.

The difference seems to be in the encoding of the deflated stream (deflating the streams in reference.pdf and the test output using qpdf results in identical files, excepts for the "moving parts").

This makes me believe that the difference is caused by a change in the output of the zlib compression, rather than by the JPEG fix.
Unfortunately I was unable to find a knob to disable compression (except using the deprecated renderToString).

@wojtekmaj
Copy link
Contributor

Duplicate of #2633

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants