@rbeezer Has anyone done work on this at the workshop this week? Otherwise, I think I can use what I learned getting one of my (much more involved) slideshows into CLI shape to address some of these things (for reveal.js, to be clear, I haven't looked into beamer yet but presumably for the sample I might be able to make some progress on that too).

#2223 addresses the first bullet point. I already have the second working (as well as the first, but I guess @sean-fitzpatrick didn't see the earlier comment) modulo the issue of names of directories not working in xsltproc (see #2155 still), including a generated image.

I just tried adding an experiment to the sample slideshow containing one TikZ image and one Asymptote image.

There are errors, which I think are mostly due to the CLI not knowing what outformat to supply:

error: * PTX:ERROR: Table of Contents level (for LateX conversion) not determined
error: LaTeX compilation of img-tikz.tex failed.
error: Re-run, requesting "source" as the format, to analyze the image.
error: Likely creating the entire document as PDF will fail similarly.
error: The transcript of the LaTeX run follows.
error: Unable to generate some latex-image assets:
error: LaTeX compilation failed for 1 "latex-image"(s).
error: Review the log for error messages, and LaTeX transcripts.
error: Images are:
error: img-tikz.tex

There are also a bunch of error messages coming from Asymptote, because the CLI is trying to build a 3D image in all formats, but not all formats are supported for 3D.

That said... the images are built, and placed in the correct place, and they show up in the slides, despite the error messages. But I get the same problem regarding widths that I get with externally generated images.

A couple of these errors were my fault, but there were two that persisted: the table of contents error for the TikZ image, and the fact that asymptote tried to build all formats for a 3D image.

But I ran into another problem: using the following markup, instead of images side by side, the asymptote image was below and to the right:

<sidebyside widths="47% 47%">
  <image><shortdescription/>
    <latex label="img-tikz">
       blah blah
    </latex-image>
  </image>
  <image><shortdescription/>
    <asymptote label="img-asymptote>
      blah blah
    </asymptote>
  </image>
</sidebyside>

Receipts:

Receipts:

That's weird. The part with both going flush left even when you ask for the sbs widths is familiar, and again probably is from something weird in pretext-common.xsl and how it computes their widths. (Using something like widths="70% 20%" can help.) But I can only assume that the different heights must be related to something in the actual images themselves, I have never seen that behavior (I don't use asymptote, only tikz and Sage).

I'll replace my test images with ones from the sample article, and push that to my existing PR.
That should address the need for images. For the other items noted:

• managed directories are already in place: they're set in the publication file
• slides are still not a target of pretext/pretext: this was observed on -dev by @ascholer yesterday
• support for CLI and target files are already in place. @oscarlevin has an open issue on the CLI repo to upgrade slideshow from a "custom" web target to a target in its own right

My PR only touches the sample-slideshow.ptx document, and the publication file. I think some work on the pretext/pretext script is probably a prerequisite for Oscar to make slideshow into an independent CLI target.

Correction: managed directories are in place, along with a CLI project file, for the copy of the sample slideshow in the pretext-cli repo.

@rbeezer do you want me to update the contents of the sample-slideshow folder to reflect CLI structure, or leave things as-is?

The CLI has the following folders: assets, publication, source, xsl. I could add these here, and update the publication file to use managed directories. Or I could keep the current flat structure for the pretext repo, and make a corresponding pull request to the CLI repo.

I observed the following quirks with Asymptote images in a sidebyside:

1. If I do a sidebyside containing two figures, where the first figure contains a latex-image and the second contains asymptote, the second figure does not appear.
2. If I remove the figure wrapper around the images, then both images appear, but the Asymptote image appears below and to the right, instead of directly to the right.

Note that the Asymptote WebGL .html file is placed in an iframe inside a div. Perhaps the styling that @ascholer is working on can address this, or perhaps we need to investigate whether the Asymptote image can be placed without the iframe.

In any case, I am ready to push changes to include two new slides: one with an external image, and one with two generated images (one TikZ, one Asymptote). It will only take a few minutes to make additional changes (project file, assets folder, etc.) if this is desired.

My plans for adding slide-show as a CLI target are mainly to remove the needed custom xsl. So that directory won't be needed.

Does the CLI still call pretext/pretext? There is no slide target there. I can build with xsltproc (with manual handling of images) or with the CLI (using the current custom setup). I'll check under the pretext/pretext hood and see if I can figure out what needs to be added.

I think I need to do two things:

1. copy the def html section in pretext.py, and swap xsl files, plus replace html with revealjs as needed.
2. add revealjs and revealjs-zip targets in pretext
3. for asset generation some logic is needed to say that if the target is reveal.js, we use the same outformats as HTML.

But Oscar is more likely to know what he is doing, so I think I should leave this for him.

I think that the pretext/pretext script can call an arbitrary style sheet. But maybe that is wishful thinking. If not, such a thing could be added or done with the CLI.

The main reasons to stop using custom are to remove the xsl from the project directory, and to ensure the right assets are built.

I have pretext/pretext doing everything except writing the slides.html output file. So far I haven't figured out how to make that happen. I'll see what I can figure out at the next airport.

Tagging work me (@ascholerChemeketa). @sean-fitzpatrick doxed non-work me :)

Ah, sorry! That was the first suggestion that GitHub gave me!