Latex-image in slideshow?

[D. Brian Walton]

I've been experimenting with using the slideshow structure. When I added a latex-image element so that I could have a tikz generated image on a slide, the routine broke.

First, I discovered that the #docinfo element for the default slideshow did not have a latex-image-preamble defined. So I added that to include the appropriate tikz/pgfplots includes.

However, then it still reports back as a failure even though it appears the single-image latex file appears to be processed correctly. 

error: * PTX:ERROR: Table of Contents level (for LateX conversion) not determined

I think this is because the table of contents structure in the variable toc-level-override is not defined in the case of slideshow (pretext-latex-common.xsl)

Trying to build a second time immediately results in no errors because presumably the image file is present now.

The last issue then is that the image never seems to scale to fill the <image-box> #div that contains the resulting image. If I add the attribute width="100%" to the generated html, then the image seems to match what I would have expected.

Brian

[David Austin]

I can't help with the first problem, but the sizing issue looks familiar, assuming you're making SVG from the TikZ source.  If the #svg element has a @width and @height attribute set, then the image doesn't scale properly in a slideshow (it works fine in an html build).  If you have @width="w" and @height="h", remove those and set viewBox="0 0 w h", where w and h are the appropriate values, and you should see the expected behavior.  Of course, this isn't a sustainable solution, but it points to something different in the way images are handled in the slideshow and html builds.

David

David

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CAH7VRo%2Bbw5%2BDc1K21ieRuPCy01%3DLWQmM%3DmaFFVzpi5sWrr9GZw%40mail.gmail.com.

[Rob Beezer]

Dear Brian,

It may be the stylesheet that "extracts" the #latex-image that needs to set some sort of level for ToC, etc. In any event, I think you are on the right track. You could be the first to put a #latex-image in a #slideshow!? It will be a bit before I can fully investigate and formulate a fix, but it should be straightforward.

As for sizing, whatever Reveal.JS is doing is a mystery to me. David's suggestion might be evidence of something. This really needs a real close look.

Thanks for the report.

Rob

>> <https://groups.google.com/d/msgid/pretext-dev/CAH7VRo%2Bbw5%2BDc1K21ieRuPCy01%3DLWQmM%3DmaFFVzpi5sWrr9GZw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

[kcri...@gmail.com]

It may be the stylesheet that "extracts" the #latex-image that needs to set some sort of level for ToC, etc. In any event, I think you are on the right track. You could be the first to put a #latex-image in a #slideshow!? It will be a bit before I can fully investigate and formulate a fix, but it should be straightforward. 

I have a project (only for local use, currently) which has dozens of these.  I've had very similar struggles.

 

As for sizing, whatever Reveal.JS is doing is a mystery to me. David's suggestion might be evidence of something. This really needs a real close look.

If I recall correctly, in the past, the revealjs adaptation was very directly based on the html conversion, but had a few things just ripped out completely and very simply rewritten for convenience.  So it was pretty easy to adapt the xsl to take a width parameter (which I used in my own source for the slides) and plop it in for the images (not just these) to scale correctly.  

That naive strategy no longer works with a less brute-force adaptation of the html conversion.  Now, the only workaround I've found to get these (svg, yes) images to scale nicely is to put them in a side-by-side.  (I usually just put explanation of the latex-image in the other half of the sbs, otherwise I just change the font size a LOT to zoom in on the figure in class.)  Maybe this will help track down what the problem is.

[D. Brian Walton]

In terms of sizing, I have discovered that because the surrounding <div> has the relevant sizing information from PreTeXt (@width), I can work around the issue by adding and then including assets/css/custom.css that contains the following:

img.contained {
    width: 100%;
}

I don't have enough experience with the class organization and styling to know if I created a problematic side effect for some other element that I'm not including.

Brian

--

You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/ebedb9f6-604f-4ee5-a817-c062362b849dn%40googlegroups.com.

[Rob Beezer]

@KDC - thanks for the accurate history lesson. The original implementation was too ad-hoc, ignoring opportunities for code re-use. We will be in much better shape now long-term for things like maintenance and code clarity, even if experimentation is a bit more constrained. We have built in some hooks to allow experiments, as Brian has discovered.

I think your observations about #sidebyside confirm some of my suspicions, but I can't easily browse the XSL right now.

@Brian - thanks for that CSS experiment. I think "contained" refers to situations where the #image is already in a box/div that is set to the desired width, such as a panel of a #sidebyside. See KDC's remarks.

@CSS specialists - could we run with Brian's suggestion as a PR? Things are not great right now, so even if this is imperfect, it could be a good starting point for improvements. We could adjust HTML, maybe by overriding the "image-inclusion" template?

Rob

>> <https://groups.google.com/d/msgid/pretext-dev/ebedb9f6-604f-4ee5-a817-c062362b849dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

[Andrew Scholer]

The rule Brian added to his show exists in vanilla html CSS, but not in the very stripped down Reveal JS. Seems fine to add.

The SBS rendering for Reveal is different than vanilla HTML. No idea why, just reporting what I see. Currently, nothing forces the SBS container to be full width. The SBS with two images in the sample show doesn't grow at all. That seems essential for attempts to make images at the desired sizes.

I'll PR something with the two fixes.

That said, to echo Rob's comments about the state of the code, if Reveal is going to be a first class format it really needs a deep cleanup and a much more extensive set of tests.

Andrew

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAwNS5iZWV6ZXI.1769455038%40pnsh.