The files used in creating the images for the PGlateximage.pl and PGtikz.pl macros are created in the /opt/webwork/webork2/tmp directory. So check permissions on that directory. Make sure it is readable and writable by the server user.
Permissions seem OK. That folder was owned by wwadmin with group www-data. I tried changing the owner to www-data, but that didn't change anything.
I also tried installing texlive-full; my install passed all checks, but just in case... This also didn't help.
The other thing I tried was uncommenting the part of localOverrides.conf that sets /var/www/html/wwtmp for temporary files, but that didn't make any difference.
I always get the same error messages as in my original post.
I also tried installing texlive-full; my install passed all checks, but just in case... This also didn't help.
The other thing I tried was uncommenting the part of localOverrides.conf that sets /var/www/html/wwtmp for temporary files, but that didn't make any difference.
I always get the same error messages as in my original post.
Sorry to come back to this again. It is still broken for me, and I don't know why. The server I use for PreTeXt is still on 2.18, and TikZ images build fine there. So far I haven't found any obvious differences other than the WW versions. Permissions seem OK, and I've applied the dvisvgm patch in the installation manual for 2.19. I can build a pdf to svg using dvisvgm directly from the command line.
But that is using the --pdf option. I notice that the error messages suggest it is looking for a DVI file. But if I'm using XeLaTeX, there will be no DVI, only PDF.
I'll keep poking around to see if I can find any other differences.
But that is using the --pdf option. I notice that the error messages suggest it is looking for a DVI file. But if I'm using XeLaTeX, there will be no DVI, only PDF.
I'll keep poking around to see if I can find any other differences.
There are two different tmp locations that the web server needs write access to. The web-accessible images end up in /opt/webwork/webwork2/html/tmp, but the LaTeX is compiled in /opt/webwork/webwork2/tmp.
Have you checked that both of those locations are writeable by the web server?
Interesting. There is no /opt/webwork/webwork2/html folder on my server. (And I can't find a step in the installation instructions that would have created it.)
But it could be that you mean /opt/webwork/webwork2/htdocs/tmp
On both of my servers, that folder is owned by wwadmin, with group www-data, and permissions set to 775.
Inside the htdocs/tmp folder are course folders. All of these are owned by www-data with 775 permissions.
The error messages I'm seeing when opening a problem in the problem editor suggest that XeLaTeX compilation is successful, but something is going wrong when converting the resulting PDF file to an SVG.
Sorry, that should say htdocs, not html, but that wasn't the point. Have you checked /opt/webwork/webwork2/tmp, which is completely separate from htdocs/tmp?
There is some confusion here about xelatex. You probably have xelatex as the engine that produces a PDF hardcopy of a set.
But the engine that produces tex-based images is not something you can configure, and is always plain "latex". Even when you are making a PDF harcopy, these images are processed using latex, dvips, and ps2df, and then the resulting PDF image is included as an image file in that hardcopy. As opposed to dropping the raw image tex code into the tex file for the hardcopy.
So there is always a dvi file for these images, and then dvisvgm does its thing for making the SVG. That is, when things are working as expected.
This does mean that text and such that you would need xelatex for should not be used inside one of these images.
But the engine that produces tex-based images is not something you can configure, and is always plain "latex". Even when you are making a PDF harcopy, these images are processed using latex, dvips, and ps2df, and then the resulting PDF image is included as an image file in that hardcopy. As opposed to dropping the raw image tex code into the tex file for the hardcopy.
So there is always a dvi file for these images, and then dvisvgm does its thing for making the SVG. That is, when things are working as expected.
This does mean that text and such that you would need xelatex for should not be used inside one of these images.
To answer Danny, yes, the permissons and ownership on both folders is what it should be. (And the same in both cases.)
But Alex's response might suggest what is going wrong. The error message that I get when I open a .pg file with a TikZ image in the problem editor contains the full LaTeX log file. It begins with "This is XeTeX, Version 3.141592653-2.6-0.999995 (TeX Live 2023/Debian) (preloaded format=xelatex)" and ends with "Output written on image-dvisvgm.pdf (1 page)." After that I get the error message.
So it seems that the TikZ routine *is* using XeLaTeX, and *is* producing PDF, although it would seem that it shouldn't be. This suggests that I must have changed the TeX engine for images by mistake in a configuration file.
And yes: in site.conf it seems that I changed $externalPrograms{latex} to use xelatex.
Changing it back to latex fixes the problem!
When you are editing a PG problem, and you click to see PDF output, you are basically making a hardcopy of a one-problem assignment. It is expected that this would use xelatex (or whatever you have configured for $externalPrograms{latex2pdf} in site.conf.)
If that one PG problem happens to use a tex-based image, then plain old latex will be used as I described before to make a PDF image. That image will be included using \includegraphics into the .tex file on which xelatex is running.
If that one PG problem happens to use a tex-based image, then plain old latex will be used as I described before to make a PDF image. That image will be included using \includegraphics into the .tex file on which xelatex is running.
OK, so I was wrong to say you cannot configure the engine that is used here. In site.conf, what do you have for:
$externalPrograms{latex} = "/usr/bin/latex --no-shell-escape";
Did you change that to xelatex? It should remain latex or something that makes dvi. For hardcopy production, there is separately
$externalPrograms{latex2pdf} = "/usr/bin/xelatex --no-shell-escape";
Have you checked that site.conf was updated to follow changes to site.conf.dist?
Sorry, I may not have been clear: this was exactly the problem: in site.conf, I had changed $externalPrograms{latex} to use xelatex instead of latex, and this is why it was not working.
I changed it back, and now it is working as expected.
I changed it back, and now it is working as expected.
No, I had some wires crossed reading your message, sorry!