WeBWorK Main Forum

Image generation problems on 2.19

Image generation problems on 2.19

by Sean Fitzpatrick -
Number of replies: 13

I'm running into errors trying to build the sample problem for the PGlateximage macro.

XeLaTeX and dvisvgm are installed, and it seems like the PDF is being created, but conversion is failing.

Here is the tail end of the error message (the rest is generic LaTeX output):

  • Output written on image-dvisvgm.pdf (1 page).
  • Transcript written on image-dvisvgm.log.
  • Image file production failed. at [PG]/lib/LaTeXImage.pm line 281.
  • Error generating graph for [WW]/htdocs/tmp/Math-1560-Fall-2023/images/f50e8de1-4bf4-3917-aa4f-ecb342158862___f3e4b3d2-bf24-39c8-990b-8dcbc0c7dfbb.svg at [PG]/lib/PGcore.pm line 606.
  • The dvi file was not created. at [PG]/lib/LaTeXImage.pm line 231.
Also, the static image file used in the sample problem is missing, but this isn't relevant to the current issue.
In reply to Sean Fitzpatrick

Re: Image generation problems on 2.19

by Glenn Rice -

Which sample problem specifically are you working with?  Is this the problem title "Inserting Images in PGML"? That is the only sample problem that uses the PGlateximage.pl macro. That problem works fine for me.  Although it doesn't work in hardcopy unless you remove the image that is stated to not work in hardcopy.

Or are you talking about some other problem from somewhere else?

In reply to Glenn Rice

Re: Image generation problems on 2.19

by Sean Fitzpatrick -
Yes, that's the one. In the Problem Editor, I clicked on Sample Problems, then Sample Problems by Macro, and then selected PGlateximage.pl.
I downloaded the pg file, copied the contents, and pasted them into the problem editor.

It seems to be building a PDF OK, using XeLaTeX, but then I get the warning about the image production failing that I posted above.
Perhaps dvisvgm is not succeeding? Or a permissions issue? The htdocs/tmp folder seems fine, but I think the PDF is built somewhere else.
In reply to Sean Fitzpatrick

Re: Image generation problems on 2.19

by Glenn Rice -
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.
In reply to Glenn Rice

Re: Image generation problems on 2.19

by Sean Fitzpatrick -
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.
In reply to Glenn Rice

Re: Image generation problems on 2.19

by Sean Fitzpatrick -
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.
In reply to Sean Fitzpatrick

Re: Image generation problems on 2.19

by Danny Glin -

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?

In reply to Danny Glin

Re: Image generation problems on 2.19

by Sean Fitzpatrick -

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.

In reply to Sean Fitzpatrick

Re: Image generation problems on 2.19

by Danny Glin -

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?

In reply to Sean Fitzpatrick

Re: Image generation problems on 2.19

by Alex Jordan -
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.
In reply to Alex Jordan

Re: Image generation problems on 2.19

by Sean Fitzpatrick -

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!

In reply to Sean Fitzpatrick

Re: Image generation problems on 2.19

by Alex Jordan -
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.

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?
In reply to Alex Jordan

Re: Image generation problems on 2.19

by Sean Fitzpatrick -
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.
In reply to Sean Fitzpatrick

Re: Image generation problems on 2.19

by Alex Jordan -

No, I had some wires crossed reading your message, sorry!