You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
then the screenshot directory is calculated as /path1/path2/. I would not expect it to append the parent path from index.pdf to the screenshot directory.
The only way to get it work correctly atm, is to calculate the relative path from /working/dir back up to the filesystem root and then pass that as the screenshot directory and output to the same folder as where the PDF will be.
There is an additional issue to this. When using something like ../.. on Windows, the path to the screenshot file will be illegal. For example for C:\path2\index.pdf it will resolve the JPG file to C:\C:\path2\index.pdf. (Yes, the drive letter is repeated).
I have a local patched decktape to workaround this problem. My solution was to treat any path passed on the --screenshots-directory flag as an absolute path. In decktape.js, I simply replaced the current implementation with this:
This approach would seem to solve the immediate issue, ie. current path.join logic is broken. And it would also seem to address any issues related to platform specific paths. I think. So perhaps it might make sense to adopt this approach here, as a general fix for the handling of this flag. Just food for thought.
If I run something like
then the screenshot directory is calculated as
/path1/path2/
. I would not expect it to append the parent path fromindex.pdf
to the screenshot directory.The only way to get it work correctly atm, is to calculate the relative path from
/working/dir
back up to the filesystem root and then pass that as the screenshot directory and output to the same folder as where the PDF will be.The text was updated successfully, but these errors were encountered: