PTXprint [2.4.3] - Error!
Failed to create: wPP_Default_GEN_ptxp.pdf
------------------------------------------------------------------------------------------
Oops! Something unexpected happened causing this unhandled error.
Try using the 'Tidy Up' button on the Help tab and then try again.
If you are still unable to proceed, use the 'Create Archive...' button
on the Help tab to create a .zip file. Send it to your PTXprint support person
for further assistance. Please include a description of the problem, and if
known, state which setting was changed since it last worked.
PTXprint Version 2.4.3
I get this same error on all projects.
I see some when they get Failed to create some further error but this one is just unhandled.
I am running Windows 11 in Parallels on macOS Sonoma. I do have Paratext with Publishing Assistant working as expected on this machine. I have typesetting rights and above on the projects I’m trying.
Hi @Corey_Garrett
Welcome to the PTXprint community. It is hard to see why it might be failing without some other information, but looking at the rather long and non-standard path to “My Paratext 9 Projects” makes me suspect that it is failing due to that.
Keep in mind that the technology underlying PTXprint (TeX) is approaching 50 years, and so it is rather particular with pathnames. There is a way to test whether it works with a more reasonable path to the project:
(Temporarily) copy the wPP folder to another location, say C:\Temp\wPP
Then adjust the Properties of the shortcut to start PTXprint with the -p flag pointing at C:\Temp
and then see if you can print normally from that location. Hopefully it is as simple as that. If not, then we will have to track down yet another possible cause.
For any following after here with long paths to Paratext, final form of the solution is to make a symbolic link to your Paratext folder and point the shortcut to it.
That’s certainly a good trick!
As to the bug, I see that it is crashing on the file deletion. That is handled by the python side of things, so I’d guess that it is almost certainly getting triggrered by unexpected things in the path name, e.g. the comma, rather than the length.
Though, actually, if that’s really the first run, maybe it’s just moaning that its temporary path doesn’t exist yet, so it can’t delete it.
If it had been from the XeTeX side of things, then I’d have blamed the spaces in file names / directory names. Spaces are for separating arguments as you type them on the command-line, after all. (No matter what your graphical user interface might want you to believe!)