** Using WeBWorK **

Below is the error message that we get when generating pdf files. ----------------

The error is:

WeBWorK has encountered a software error while attempting to process this problem. It is likely that there is an error in the problem itself. If you are a student, report this error message to your professor to have it corrected. If you are a professor, please consult the error output below for more information. Error messages

Failed to generate PDF from tex Error details

Call to /usr/bin/pdflatex --shell-escape failed: Inappropriate ioctl for device Some pdf output was produced and is available here. pdflatex ran, but did not succeed. This suggests an error in the TeX version of one of the problems, or a problem with the pdflatex system.

<| Post or View Comments |>

My first guess is that someone accidentally changed permissions on webwork2/tmp, so I would check that.

Next, you could look in the apache error log for clues.

Next, I would set $WeBWorK::ContentGenerator::Hardcopy::PreserveTempFiles =1; in Constants.pm, restart the web server, and then trigger the error. Then you should be able to look at the latex file, run pdflatex on it yourself to see if that reveals anything.

John

<| Post or View Comments |>

In this case a problem 8 added to set 0 was a screenHeader.pg file which is only suitable for display on the screen. It gives TeX fits, mainly because it contains equations that are not enclosed by ( ) (begin math and end math) symbols.

<| Post or View Comments |>

------------------------

WeBWorK Error

WeBWorK has encountered a software error while attempting to process this problem. It is likely that there is an error in the problem itself. If you are a student, report this error message to your professor to have it corrected. If you are a professor, please consult the error output below for more information.

Error messages

Failed to generate PDF from tex

Error details

Failed to create /usr/local/webwork/tmp/webwork-hardcopy.1pbqkjJv/dance.999999999.Homework1.pdf for no apparent reason.

--------------------

So I checked permissions on /usr/local/webwork/tmp.

In fact, I set them to 777 and tried again. That didn't help. (They were already at 775, and the director is in the same group as apache, so that should have been OK anyhow).

The Apache log reveals nothing.

I tried changing the PreserveTempFiles variable (and restarting Apache) as John suggests. No files seem to be being created at all in /usr/local/webwork/tmp, which I don't understand!

Hal

<| Post or View Comments |>

What I would expect to see then is various files created inside

/usr/local/webwork/tmp/webwork-hardcopy.1pbqkjJv/

The actual temporary directory used to work with TeX is defined at

# Contains non-web-accessible temporary files, such as TeX working directories. $webworkDirs{tmp} = "$webworkDirs{root}/tmp";

which is in your global.conf file, but the address in the error message looks like the default.

One thing to make sure of is that the webserver can actually get to that directory. This means that it needs execute permission on all of the directories above tmp and it needs write permission on tmp itself (which apparently it already had).

If the temporary files are being preserved then you should see something like

bash-2.05b$ ls webwork-hardcopy.UK7Fq4Od/
hardcopy.aux    hardcopy.log    hardcopy.tex  

However, reading through the code in Hardcopy.pm I also see a bug in the error message. at about line 610 there is a message:

"Failed to create $finalFile for no apparent reason.\n"

"Failed to create $hardcopyFilePath for no apparent reason.\n"

I suspect that the place where the permission problem is occuring may be in the destination file for delivering the hardcopy file. This should be the directory:

.../myCourse/html/tmp/hardcopy/

and the file name will be something like Homework1.pdf (the dance.999999. bit in the file name above looks a bit fishy to me, but it might be ok).

Hope this helps.

-- Mike

<| Post or View Comments |>

So checking global.conf for the 38th time, I now notice that I've specified the latex command where I was supposed to have specified the pdflatex command.

<| Post or View Comments |>

The only thing I can come up with is to change the usernames to the students' university id numbers. Of course, the problem is that the username in webwork appears to be the one thing that can't be changed in the database for each user.

Does anyone have a suggestion?

Thanks!

<| Post or View Comments |>

<| Post or View Comments |>

MSIE has several problems, but we have never had a report of it not being able to view png images and obviously thousands of students are using it to view problems in images mode. Does your course allow practice users? If so, can you give the URL as I would like to check this out for myself.

Unfortunately TeX has a problem with periods in directory names. A hack might be to do the following. When a user_id is used as part of the name of a directory, first replace all periods by (say) underscores. This would have to be done both when the directory is created and when it is read. Does someone have a better idea?

Arnie

<| Post or View Comments |>

In the TeX log file I don't get any error message, not even warning. I am stripping down the TeX file, and got to the following short file that slipps through TeX without generating any dvi or pdf file.

\documentclass[10pt]{amsart}
\usepackage{multicol}
\begin{document}
The primary purpose of WeBWorK is to let you know that you are getting the correct answer or to alert
\begin{multicols}2
\columnwidth=linewidth
\end{multicols} % close off the columns from the set above
\end{document}

Interesting part: I tried this TeX file on three different tetex:
Did not get dvi/pdf with tetex-3.0-4 (fedora 4),
but got the right output with tetex-2.0.2-21.3 (fedora 3)
and also with tetex-1.0.7-57.1 (redhat 8)

Classes starts tomorrow. Any help would be appreciated.

Andras

<| Post or View Comments |>

whatever this platex is, renaming multicol.sty to multicol.sty_no in that directory solved the problem.

Andras

<| Post or View Comments |>

I am very interested in the hack you suggested. I think we can get it to work, but I need to know where I need to put the hack. Could you tell me which files to edit? Thank you!

Jeff

<| Post or View Comments |>

I see the problem with png's on your site but that's the only place I have seen it. Doing a Google search for "problem png MSIE" leads me to think that the problem may have to do with the transparency and number of colors in your png's.

What version of dvipng are you using?

Are you using the standard

$WeBWorK::PG::ImageGenerator::DvipngArgs = "-bgTransparent -D120 -q -depth";

in .../lib/WeBWorK/Constants.pm

Arnie

<| Post or View Comments |>

We are using dvipng version 1.6 and are using the standard values in Constants.pm.

Jeff

<| Post or View Comments |>

In case there is still some question about pdf generation, the periods in user names (and the periods in filenames) should not be the problem with pdf generation. As Mike described above, when webwork 2 makes pdf files, it always uses a latex file named hardcopy.tex. It is put in its own temporary directory to avoid collisions if more than one pdf is being generated at once. That happens in one spot for the system, usually /opt/webwork2/tmp.

Once the pdf is created (and is now "hardcopy.pdf"), it is copied into /opt/webwork2/courses/MyCourseNameHere/html/hardcopy to have a filename which looks like MyCourseName.loginname.setname.pdf, and that file is sent to the student.

John

<| Post or View Comments |>

I think there is a problem with periods in user names. I just created a user with user_id "new.user" and tried to download a hard copy of a set. I get the error:

! LaTeX Error: Unknown graphics extension: .user-1407-setDerivatives1prob14image1.png.

so I assume Latex "new.user" is part of the png file name and LaTeX is using everything after the first period as the extension.

As a further test, this set can be downloaded successfully by users without periods in their user_id name.

I'll report this as a bug.

Arnie

<| Post or View Comments |>

You're right. I forgot about the names made up for on-the-fly images. The cvs version of pg/cvs/PGgraphmacros.pl should fix that problem.

Up until just now, that file had not changed in 15 months, so it should be safe to drop it into a running system.

If anyone runs into other kinds of graphics which trigger an error on pdf generation, please post here.

John

<| Post or View Comments |>

Also, we are having problems with users (with any type of username) not being able to download pdfs when they check the box to include answers. Does anyone know how we can fix this problem?

Finally, we are using WW2 from the tarball that is dated in late June. Would updating from the CVS fix the problems we are seeing?

Thanks!

Jeff

<| Post or View Comments |>

cvs update -A -d

The -A tells the update mechanism to take the latest versions of all files and the -d directive allows new directories to be constructed if needed.

I'd recommend updating to the latest CVS version. It may well fix many of the problems you are seeing, and it makes it much easier to fix and distribute patches for any remaining problems.

-- Mike

<| Post or View Comments |>

Finally, you may need to update the structure of the database for your courses. There is a script provided in the bin directory for doing this.

John

<| Post or View Comments |>

Could you or someone give more details on how to update the structure of the database?

Thanks,

Bob

<| Post or View Comments |>

It is bin/wwdb_addgw. It can handle sql and sql_single courses. For sql_single, I think it can figure out what courses you have. For the older sql, you have to tell it the course name. If you accidentally run it twice on a course, it is not a problem.

John

<| Post or View Comments |>

We are using dvipng version 1.6 and are using the standard values in Constants.pm.

dvipng version 1.6 now produces images with alpha-channel transparency (new in this version). Unfortunately, MSIE does not handle alpha transparency without a lot of extra hoopla added into the image tag (I ran into this when writing the new image-font mode for jsMath). If you change -bgTransparent to -bgtransparent (i.e., remove the capitalization) in Constants.pm, then it will produce regular transparency rather than alpha-channel transparency, so it should work correctly with MSIE again. Don't forget to remove the old images, since they are cached by WW. (This process is documented elsewhere on this discussion board).

For those who don't know, alpha-level transparency would allow the images to smoothly blend into any background color. Without it, the antialiasing goes to a fixed color, so if you put the images on a different background, they won't look right.

Davide

<| Post or View Comments |>

We should probably modify Constants.pm to reflect this.

# Arguments to pass to dvipng. This is dependant on the version of dvipng. # # For dvipng < 1.0 # $WeBWorK::PG::ImageGenerator::DvipngArgs = "-x4000.5 -bgTransparent -Q6 -mode toshiba -D180"; # For dvipng >= 1.0 # $WeBWorK::PG::ImageGenerator::DvipngArgs = "-bgTransparent -D120 -q -depth"; #

Arnie

<| Post or View Comments |>

<| Post or View Comments |>

Any thoughts?

<| Post or View Comments |>

Are you SURE the change to lower-case t is in effect, and are you SURE you deleted the equation cache that is actually in use? (For example, if you moved the temporary folder somewhere else, you might have erased the equations from theior original position, but not the position where they are actually being used.)

Can you be more specific about the complaints for AOL? Are they also about images not being shown, or something else?

Davide

<| Post or View Comments |>

I'm having my sys admin check on some of the details that you mentioned. We did do a hard reboot after I made the change in "t" and apache was restarted again by the sys admin afterward for another reason. So, I thik the right Constants.pm is in effect. I'll let my sys admin check the other details.

With AOL, I didn't get a full report from the students. They just indicated that they could not see the images, much as in IE.

Jeff

<| Post or View Comments |>

Once the sysadmin has some time, get him to look closely at the apache setup. You should not have to reboot the entire system in order to restart the apache server. I doubt that is causing your current problems, but it's a sign that something isn't set up quite right and who knows what side effects it has. In trouble shooting that original dvipng problem I'm pretty sure that the apache server was not actually restarted until we did the hardware reboot.

Good luck.

-- Mike

<| Post or View Comments |>

Can you enable some guest logins for a course and point it to us? Looking at it through IE might help shed some light on it for us.

John

<| Post or View Comments |>

http://mathww.mercer.edu/webwork2/jkdtest/

Thank you for your help!

Jeff

<| Post or View Comments |>

John

<| Post or View Comments |>

Arnie

<| Post or View Comments |>

Can you view http://devel.webwork.rochester.edu:8002/webwork2/gage_course_single_sql/ (use login/password practice1/pracctice1) all right on a PC MSIE browser? We are using dvipng 1.5 on that site.

-- Mike

<| Post or View Comments |>

It looks like common things such as F(x) and \tan^{-1}(x) have alpha transparency, while the problem-specific images do not. This suggests that you didn't (fully) clear the equation cache when you changed the dvipng settings. You probably need to use the remove_stale_images command as discussed in

http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$3530#3534

and

http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$2929#2933

to remove all the images. Otherwise old images that were generated before you changed the transparency will still cause MSIE trouble. The new (non-alpha images) appear to work fine for me, so I think the problem will be taken care of if you can clear the cache. (You might also want to clear the cache in your BROWSER after you have done this, just to be sure you are getting the latest copy from the server.)

Davide

<| Post or View Comments |>