This PR removes the inconsistency between Linux and OSX versions of wkhtmltopdf.
When there are missing assets (images, JS etc):
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)
Show wkhtmltopdf exit status on errors
Treat status code 2 as success
Could you address the test failures (preferably by not modifying the tests themselves) on Travis?
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.
(BTW, the #187 can be merged separately)
@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!
@dnagir do you have the chance to rebase this PR?
Closed since #209 ostensibly handles the same issue.
Actually looking at the diffs, #209 and this are different enough
I'm seeing the opposite behavior, with PDFKit 0.6.1 on OSX with missing images it fails with:
If I revert to PDFkit 5.x it generates the pdf with broken images as expected.
@dnagir could you rebase this pull request?
@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?
Ok @dnagir. Sorry this sat so long without a good response.