Integrate mdpdf as the primary converter #162
Comments
|
Hi @travs, amazing to see the work you've been doing. It's great to see the work being done to try out this transition! I've not had a chance to dig through this yet specifically but I get the feeling it'll be something to do with either PhantomJS (used to produce the final pdf) or highlightjs (used to add syntax highlighting when rendered inside of phantomjs). I'll pull the branch and have a dig around to see what I can find but I'm not super well versed in atom or coffeescript. Would you be able to grab a sample of the options and data being pushed into the |
|
On a second look this is actually being caused by a line of handlebars code, I'm just going to dig into their source now and see what's cracking but it looks to me like they're calling |
|
The offending line seems to be a piece of handlebars code, specifically:
|
|
Just a hunch, but instead of unsafe eval, try using the loophole unsafeNewFunction as that seems somewhat similar to the actual handlebars code that's being executed. It's a longshot but it's worth ruling out since that's actually closer to the code being run. |
Just tried this and getting the same error. Also tried For the options I just put in something minimal: let options = {
source: inPath, // using README.md from this project
destination: outPath, // ./README.pdf
pdf: {
format: 'A4'
}
};I couldn't find an
It also may be that I am using I'm not 100% sure how |
|
In mdpdf I use handlebars to pull together several things into one html document.
To get all of these into one html document I'm using handlebars almost as you might in an express application. There are some alternatives which I'd be happy to experiment with. My first go-to would be to look at the lodash However this would be quite a change to the module as the majority of the code is just building that final html document. It would be good if we could look at Q just to be sure that this isn't something loophole can fix. If not then I can take a look at a new templating engine and see what might work. |
|
This might also be really dumb, but in the past I've seen libraries which support promises have had issues with anonymous arrow functions |
|
@BlueHatbRit However, I have been able to produce PDF output by wrapping some calls within const loophole = require('loophole');
// ...
const html = loophole.allowUnsafeNewFunction(function() {
return template(local)
});I'm not sure if you would accept this change in The PDF output is, for some reason, massively oversized when I use the code above (invoked from the This is what the output of this project's README looks like: When I call the unmodifed Do you have any idea why this could be happening? Some stylesheet not being applied, or something? |
|
@travs I've had a look at the loophole repo and it seems it gets published in JS (not coffee) and has no external dependencies. That means I'd be happy to look at merging that change into mdpdf until we can find a better solution. If you wanted to go ahead and submit a PR for that then I'll run a few tests to make sure it doesn't add too much overhead and then we'll get it merged and released. That PDF output is very strange! Could you pass me an updated version of the parameter values you're using to invoke mdpdf? If the same version of the CLI is coming out fine then the only two things I can think of are:
Have you tried applying the debug flag to check the html output? That should reveal any issues as that html is fed straight into phantomjs. |
|
I have this minimal script that I run to get the messed up output: const mdpdf = require('mdpdf');
const path = require('path');
let options = {
source: '../markdown-pdf/README.md',
destination: path.join(__dirname, 'output.pdf'),
pdf: {
format: 'A4'
}
};
mdpdf.convert(options).then((pdfPath) => {
console.log('PDF Path:', pdfPath);
}).catch((err) => {
console.error(err);
});This is actually using an unmodifed version of The I'm really confused by this, since that script is basically the up-and-running script from the For reference I am on linux ( updateForgot to upload the HTML output from debug. |
|
@travs the cli output you linked at the bottom is giving me a 404, are you sure it's public? Cheers for that code that's really helpful! I'm on macOS so we might get a difference but I'll give it a go right now. I am considering moving over to the newly released Puppeteer by the Chrome team but that's probably a way off as it'll mean quite a lot more code being introduced, just a heads up though. I'll run this through and see what I get out. |
|
Mate, I'm consistently impressed with how quick you are. I was just about to update my comment again but you beat me to it. |
|
@travs I'm impressed how you manage to catch me at the right time! What was the issue? I'd be interested to know so I can make sure the docs are better for future users. Looking forward to the PR, excited to get mdpdf rolled into this module! |
|
@BlueHatbRit Responded over here. |
|
@travs your changes have been integrated and a release has been published to npm under 1.5.1 - https://www.npmjs.com/package/mdpdf. The documentation changes mentioned on the PR will be sorted over the next couple of days, I pushed the release before that to help you get moving fasting. Ping me again if there's anything you need help with for this issue, I'll keep an eye on it anyway to see how you make use of mdpdf :) |
|
@BlueHatbRit Wizard! You may see me coming for advice on testing for pdf output soon, haha. For now I'll make the new release with |
|
@travs haha no worries! Testing thats actually something I've struggled with a bit, validating pdf output is not easy. A lot of what I've done so far is just checking that the conversion process outputs a pdf. The problem is, it's quite hard to even pre-generate a pdf and diff the contents because (I believe) that pdf's contain some data with timestamps etc. I started reading through the pdf spec a few weeks back to see if I can figure out a way to check parts of a pdf properly. However the open spec is huge and I've not got far enough to come up with a plan yet. It's definitely something worth thinking about for both our modules though. Feel free to tag me in any issues that crop up if the release causes any issues for users, I'd be happy to take a look if they're getting really mental output that is todo with my module / the space in-between our projects. |
|
Just scrolling through the issues on this repo, the addition of mdpdf should help resolve #147 really easily, worth tagging it here even though it's a bit older. |
|
@travs I was just thinking, when this change is shipped I'll put a link to this module for atom users in the mdpdf readme. If that's alright with you, should I use the atom plugin page or the repo page? Your call, but I expect the atom plugin page is probably the best choice. |
|
@BlueHatbRit hey hey, just seeing this now. |
|
@travs oh that's great thanks, you did all the work so I wouldn't want my name anywhere else haha. Here's the link back if you wanted to check it out -> elliotblackburn/mdpdf@8fade1b. I'll be pushing it to npm later on today. |
|
@BlueHatbRit Looks great, thanks! |
Changing because the output of
mdpdflooks so great.Finally now getting around to starting this.
I have one commit pushed to this branch, but am getting an error regarding atom's content security policy, like this:
It appears that this is due to some
evalcall inmdpdf(most likely in one of its dependencies), but I couldn't find such a call.I have tried wrapping the
mdpdfusage in loophole to escape the CSP, but I still get the error.I would much rather use the
mdpdfAPI, but if I can't get this resolved then we may have to resort to callingmdpdffrom the command line in a child process (not a clean solution).@BlueHatbRit
Do you have any idea of where such a call may be in the
mdpdfstack? If so, maybe I can help make a workaround that lets us usemdpdfinside atom given its current CSP.The text was updated successfully, but these errors were encountered: