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

Allow missing assets #188

Closed
wants to merge 4 commits into from
Closed

Allow missing assets #188

wants to merge 4 commits into from

Conversation

dnagir
Copy link

@dnagir dnagir commented Aug 9, 2013

This PR removes the inconsistency between Linux and OSX versions of wkhtmltopdf.

When there are missing assets (images, JS etc):

  • on Linux (x64): wkhtmltopdf exits with status code = 2 and does produce actual PDF (but an error is raised)
  • on OSX: wkhtmltopdf exits with status code = 0 and does produce actual PDF (and no error is raised)

This also means that no failures will occur during local development on OSX, but it is more likely to fail in production.

The spec here may need a bit of adjustment depending on what platform it is being run on, but should be a good starting point.

(This also incorporates the #187)

@sigmavirus24
Copy link
Contributor

Could you address the test failures (preferably by not modifying the tests themselves) on Travis?

@sigmavirus24 sigmavirus24 mentioned this pull request Aug 15, 2013
@dnagir
Copy link
Author

dnagir commented Aug 15, 2013

There are a few problems with the tests that I would prefer someone else to look at. A lot of the tests are failing on Travis even prior to this PR (but passing locally on OSX) so I was concentrating on the only 2 in PR.

The original description isn't accurate now after I updated to the recent wkhtmltopdf-binary gem.
Now the given spec fails with status code=1 on OSX but succeeds on Linux (status code = 0).

So it looks like there are also some differences between versions of the wkhtmltopdf as well as platform.

Not sure how to deal with it now? Maybe just using the ignore-load-errors flag should do the job.
Looks like it would be PITA to deal with all those version/platform issues as part of pdfkit.

Opinions?

(BTW, the #187 can be merged separately)

@sigmavirus24
Copy link
Contributor

@dnagir I think we're finally on our way towards having Travis successfully run tests. Could you just rebase this branch against master so we can see if the tests pass on Travis? Thanks!

@sigmavirus24
Copy link
Contributor

@dnagir do you have the chance to rebase this PR?

@sealink sealink mentioned this pull request Nov 28, 2013
@sigmavirus24
Copy link
Contributor

Closed since #209 ostensibly handles the same issue.

@sigmavirus24
Copy link
Contributor

Actually looking at the diffs, #209 and this are different enough

@marcus
Copy link

marcus commented Feb 27, 2014

I'm seeing the opposite behavior, with PDFKit 0.6.1 on OSX with missing images it fails with:

  • Exit with code 2 due to http error: 404 Page not found

If I revert to PDFkit 5.x it generates the pdf with broken images as expected.

@sigmavirus24
Copy link
Contributor

@dnagir could you rebase this pull request?

@dnagir
Copy link
Author

dnagir commented Aug 12, 2014

@sigmavirus24 I'm not sure if I should do this. I'm out of touch with this PR now and don't remember particulars already. People also reported the opposite behaviour to this PR, such as #209.
So maybe it would be better to look there?

@sigmavirus24
Copy link
Contributor

Ok @dnagir. Sorry this sat so long without a good response.

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

3 participants