Open qbit86 opened 2 years ago
Did you install pagedjs-cli? This does not come with pandoc. Is it in your path?
Can you run it directly from the command line using pagedjs-cli
?
Did you install pagedjs-cli?.. Is it in your path?
Yes, as I mentioned.
Can you run it directly from the command line using
pagedjs-cli
?
I can run it in both PowerShell and in cmd. And in Git-Bash too. These are three different scripts, as far as I see in %APPDATA%/npm
.
C:\Users\...> pagedjs-cli -i input.html -o output.pdf
✔ Loaded
✔ Rendering 1 pages took 17.899999999906868 milliseconds.
✔ Generated
✔ Processed
✔ Saved to C:\Users\...\output.pdf
Sorry, I missed the info in your orginal report. I don't know what could be causing this. It could be a subtlety of Windows paths; maybe you're setting the path in a way that doesn't extend to subprocesses? Do other pdf engines work for you?
It could be a subtlety of Windows paths; maybe you're setting the path in a way that doesn't extend to subprocesses?
Maybe; I didn't set the paths explicitly. I installed node.js with installer (not nvm-windows), and installed pagedjs-cli
globally with npm:
npm install -g pagedjs-cli
This resulted in adding C:\Users\...\AppData\Roaming\npm
to user's PATH
(not system PATH
).
Do other pdf engines work for you?
Default wkhtmltopdf
does work. But the resulting PDF is of poor quality, so I had to switch to another engine.
Can you try passing in an absolute path?
Well, when I pass absolute path into pdf-engine
option it does sucessfully work...
Then, is there any way to pass the path relative to %APPDATA%
? I've tried in my defaults.yaml
:
pdf-engine: '%APPDATA%/npm/pagedjs-cli.cmd'
But this results in «%APPDATA%/npm/pagedjs-cli.cmd not found.» ${APPDATA}
doesn't work either.
I would have thought that ${APPDATA}
would work; this is the syntax for interpolating environment variables.
But it turns out pdf-engine is not one of the options we do interpolation on.
That's an oversight, I think, since you can pass in a path here. I can fix it.
I can fix it.
That would be nice, thanks. Also, please consider making pagedjs-cli
the default engine instead of obsolete wkhtmltopdf
.
Regarding the original issue. Now I've tried the same on three different Windows machines — everywhere result is the same: pagedjs-cli
works fine when I invoke it directly (even without specifying the path), but it fails to be found when I call it via Pandoc (pdf-engine: pagedjs-cli
). Maybe spawned pagedjs-cli
process indeed doesn't have access to the PATH
variable of the current user.
Unfortunately I'm an ignoramus when it comes to Windows, and I don't even have a Windows box to mess around with. Hopefully someone else can figure out what is going on here.
The change to pdf-engine
handling has been made, now; you can try a nightly.
Experiencing the same issue.
Unfortunately, passing in an absolute path --pdf-engine="%ProgramFiles%\nodejs\pagedjs-cli.cmd"
seems to work, but then it just HANGS at "Processed" whereas running pagedjs-cli standalone on a pandoc-generated html doesn't hang.
pandoc --standalone --embed-resources --defaults=../doc2/definition.yaml -f markdown-smart --pdf-engine="%ProgramFiles%\nodejs\pagedjs-cli.cmd" --output="../out/document2-pagedjs.pdf"
vs
pandoc --standalone --embed-resources --defaults=definition.yaml -f markdown-smart --output="%~dp0/../out/document2.html"
pagedjs-cli --media print -i "..\out\document2.html" -o "..\out\document2-pagedjs.pdf"
del "%~dp0/../out/document2.html"
Explain the problem.
defaults.yaml
:input.md
can be any trivial markdown file.Expected behavior was generating
output.pdf
since all required dependencies are installed:Pandoc version?
pandoc-2.18-windows-x86_64.msi
: