tikz image package for PreTeXt output

[Alex-Jordan]

This makes it such that for PTX display mode (used when producing PreTeXt output) the tikz "image" is actually a .tgz file with .tex, .pdf, .svg, and .png.

To test, check that earlier tikz examples still work. There are sample files in #557.

Next, check PreTeXt output is as described. To do that, you could use something like the following URL. You need to set:

• the server
• courseID should be a course ID
• sourceFilePath should be a file path to some tikz example file accessible from that course
• userID and course_password should be a user in the course (login proctor or higher), and their password

https://webwork.yoursite.edu/webwork2/html2xml?&problemSeed=1&answersSubmitted=0&sourceFilePath=local/BEGINTIKZ.pg&displayMode=PTX&courseID=testing&userID=anonymous&course_password=anonymous&outputformat=ptx

Ignore whatever your web browser displays and instead look at the page source. You should see something like:

<image source="/wwtmp/testing//images/4c09146e-8bc3-3ae3-aac3-ad011135bebb___ca219939-7303-3697-8505-574f0e733dc4.tgz" />

with that .tgz extension. Download that file (so, like from https://webwork.yoursite.edu/wwtmp/testing//images/4c09146e-8bc3-3ae3-aac3-ad011135bebb___ca219939-7303-3697-8505-574f0e733dc4.tgz) and see that it contains what it should contain.

[drgrice1]

There are some changes needed here. This breaks svg image generation as it currently stands. There are some other issues as well. See the comments.

There is another problem when generating the svg image with the ptx extension. Note that the tex file used with dvisvgm is different than the tex file used in all other cases. dvisvgm needs \def\pgfsysdriver{pgfsys-dvisvgm.def} to work properly. You might get lucky and it will still work without that depending on what is in the TikZ code. Even if it does work, the generated svg may not look as good. With your current code the pdfsysdriver definition is not added with the ptx extension, and the same tex file is used in all cases.

[Alex-Jordan]

With your current code the pdfsysdriver definition is not added with the ptx extension, and the same tex file is used in all cases.

Just to be clear, you mean the tgz extension. I decided it was inappropriate to get "ptx" down at this level in TikzImage.pl. In PGtikz.pl, if the display mode is "PTX" then that makes the extension override to tgz just like how tex display mode overrides it to "pdf". And "tgz" actually is a file extension.

Thanks for being on top of this though. I was not aware of this detail with the pdfsysdriver. I'm thinking what to do about it. I see a few obvious ways, but don't like them for various reasons.

[drgrice1]

Yeah, the tgz extension then. Was it ptx before? Not sure where I got that. In any case, it is probably better, as you said, to not have ptx at this level.

Note it is pgfsysdriver (not pdfsysdriver). It is a TikZ and PGF thing. dvisvgm uses a modified backend driver when latex is run so that it can inject postscript specials into the dvi output. Then dvisvgm uses those specials to improve its images. I am now rather well versed on this after messing with the TikZJax stuff. It uses the same technique. I actually improved on the pgfsysdriver Jim Fowler uses for TikZJax by looking at the dvisvgm version in my PGtikzjax.pl macro.

[Alex-Jordan]

Was it ptx before?

Probably, in the discussion I started several days ago.

[Alex-Jordan]

Standy by. I can't do complete dvisvgm testing but I realized I could partly do some. And am doing now.

[Alex-Jordan]

OK, I think it is ready for another look. On my system, it "works" with dvisvgm as well as it ever did, with the messed up scaling.

[drgrice1]

This is certainly not looking pretty. I offered some suggestions to clean this up some, but I almost think it would be better to just generate the image multiple times from special code for handling the PTX format in PGtikz.pl.

Edit: Scratch the PGtikz.pl idea. Just clean this up.

[drgrice1]

I just noticed that this now breaks hardcopy generation as the 'pdf' extension is not properly accounted for.

Okay, it doesn't break hardcopy generation. I forgot to remove an error inserted into the TikZ code in a problem I was using to test error messages earlier!

However, it does do something a bit silly in this case. I will add a comment to the code about it.

[Alex-Jordan]

@drgrice1 I appreciate your time reviewing this and I regret that there are so many issues. I wanted to ask at this point, if you'd prefer (a) I continue combing it out or (b) I could revert to how things were before and basically wrap it within the draw subroutine like:

if ($ext ne 'tgz')
    {what was there before}
else
    {new block of code that builds everything and puts it into a tgz}

There would be code duplication in that new block, which is what motivated me to try this way. But putting it in a new block would insulate what you already worked on so much that was already working.

[drgrice1]

Continue on the path we are on. This will work.

[Alex-Jordan]

@drgrice I believe I addressed your comments with the last four commits.

[drgrice1]

This looks good. You have addressed my primary concerns and everything works.

The only thing I don't like is the if (-r "$working_dir/image.pdf") convert else warn repetition. Note that when generating the tgz output you will get the warnings for the same latex run twice when an error occurs if you are using pdf2svg.

I noticed there is another chmod that you removed. Before this pull request the tex file permissions were also set to "0777". That doesn't seem to be needed for me on linux. I checked and that was something that @mgage had in his original TikZ pull request (#292). That may be another OSX permissions thing.

@pstaab: Could you take a look at this? See if it still works on OSX.

[Alex-Jordan]

The only thing I don't like is the if (-r "$working_dir/image.pdf") convert else warn repetition.

I think I took care of that in an upcoming commit.

I noticed there is another chmod that you removed.

I'll put it back, because it seems harmless. I did not intentionally remove it. My eyes blurred and I did not see the difference, and I convinced myself an extra copy had snuck in through copy/paste or shuffling lines of code around.

I changed the rm.

[Alex-Jordan]

I just pushed those things I mentioned in my last post. I noticed I had a typo in the commit message right before these and I couldn't help but correct it with git commit --amend before I did these newer commits. So I had to force push, and you (or anyone may need to trash the branch and get it fresh.

[Alex-Jordan]

@pstaabp I'm seconding the call if you wouldn't mind testing this again. I made even more edits after @drgrice1 's last post, including bringing back the chmod line. But it would still be good to hear that nothing is broken on your system.

[drgrice1]

Yeah, this is better.

I am not sure what is actually needed of the chmod calls, but we will see what @pstaabp's tests show.

[drgrice1]

I just pushed those things I mentioned in my last post. I noticed I had a typo in the commit message right before these and I couldn't help but correct it with git commit --amend before I did these newer commits. So I had to force push, and you (or anyone may need to trash the branch and get it fresh.

Yeah, I do the same thing for quick minor tweaks. I don't mind this on pull requests. I usually delete branches between testing in any case.

[pstaabp]

It seems to be working on my system.

[pstaabp]

Hold on. When I switch back to pdf2svg method, then I get the following:

94eabc5b___73d89ae3-bf01-3da5-94cc-7557c35d815d.svg<BR> at XXX/pg/lib/PGcore.pm line 718.
Failed to generate svg file. at XXX/pg/lib/TikZImage.pm line 269.
Failed to generate svg file. at XXX/pg/lib/TikZImage.pm line 269.
Image file production failed. at XXX/pg/lib/TikZImage.pm line 248.

[pstaabp]

Finally got this working with pdf2svg. Settings on my end. I now doubly approve this and will go ahead and pull it in.