Width's of images in worksheets

[Oscar Levin]

I think this is a bug (or a collection of bugs), but wanted to check before making an issue.  Suppose you structure a worksheet with a #sidebyside that holds a pair of #exercise elements.  In such an exercise you include an #image and put a @width attribute (not equal to 100%).  The image does not get scaled to it's desired width at all. 

If you wrap the #image with a #sidebyside (the old way for "bare" images) and put a @width for the #sidebyside, you do get scaling.  But only for the first #exercise, if you do the same thing for the second #exercise the image doesn't show up at all.

If you author an #exercisegroup in your #worksheet, then widths are respected for include #image inside #exercise.

I haven't looked at the xsl yet, or the CSS, so I don't know what the issue might be.  The sample article only has an image with width="100%".  When I'm not on deadline for creating tomorrow's activity, I'll try to make a MWE to share. 

[Rob Beezer]

It does sound like a collection of bugs.

Not sure an #image inside an #exercise inside a #sidebyside has been considered.

First question, the @width is relative to what?

(In a "normal" #sidebyside we assume an #image consumes the whole panel.)

A #sidebyside in a #worksheet, holding #exercise is a really different thing. It is meant to be a convenience for authors, to recycle it as a language for layout control. Perhaps we should identify #sidebyside in the pre-processor - normal, worksheet, interactive - and react accordingly.

When you have a MWE, or a free minute, it'll be interesting to see what LaTeX does with this.

Rob

[David Austin]

I don't mean to muddy the waters, but this sounds similar to the behavior Brian W and I have recently noted in the revealjs conversion.

--
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/MTAwMDAxMC5iZWV6ZXI.1769407897%40pnsh.

[Rob Beezer]

Not muddying the waters at all. Nor poisoning the well.

A "bare" image gets a width on the #img element, iirc. A "constained" image, like a panel of a #sidebyside fills a box/div that already has the desired width. I believe this is all controlled by a "image-inclusion" template.

Maybe *every* image should go into div.image-box? I think Andrew just did something like this in a more limited scenario?

Rob

[Oscar Levin]

We started talking about this in drop-in today, but I went to a breakout room to help someone before we could resolve it.  

Current status:

• An #image in an #exercise in a #sidebyside (in a #worksheet) is not getting the sizing info we normally put in the <div class="image-box">.  Presumably this could easily be changed to by more careful selection of templates in xsl.  Clear to me that we should fix this (it is a bug).
• A #sidebyside within an #exercise in a #sidebyside (in a #worksheet) does create a sbspanel that gets sized correctly, but CSS has rules for laying out a grid of sbspanels, and for some reason a panel in a second exercise gets pushed to grid position 2 (which doesn't exist), so the image doesn't show up.  Presumably this could be fixed with some more careful css selector.  Not sure whether this use case should be supported though.

A larger question that was raised by Andrew today was whether an image inside a sidebyside should be able to have its own @width specified, so that it could fill up just a part of its column (for example, if you wanted the figure to have a caption with the width of the sbspanel but the image inside it not.   This makes a lot of sense to me, even without a figure present: I want to divide the page into two halves, one for an image and one for a table.  I want these to both be centered in their own half but not take up the entire space of their half.  I suppose I could manage this with margins, but then I'm calculating margins and widths to get a specific look, which seems less intuitive.  

I'm going to prepare a PR that addresses the two bugs listed above, but it would be easy to also change the larger question at the same time (it might be cleaner to do both at once).  So let me know if all images in sidebyside should get widths respected and I'll solve the first issue that way.

Oscar.

[Jeremy Sylvestre]

On Tue, 10 Feb 2026 at 12:26, Oscar Levin <oscar...@gmail.com> wrote:

A larger question that was raised by Andrew today was whether an image inside a sidebyside should be able to have its own @width specified, so that it could fill up just a part of its column (for example, if you wanted the figure to have a caption with the width of the sbspanel but the image inside it not.

Yes please. This issue has been on my "bring up a discussion about this at some point" list for a while. Currently my workaround is to artificially make my images wider with whitespace so that the caption can be wider.

I also have issues with sizes of images in knowls from structure

exercisegroup/exercise/answer/image

where the exercisegroup has @cols greater than 1.

On Sun, 25 Jan 2026 at 23:11, 'Rob Beezer' via PreTeXt development <prete...@googlegroups.com> wrote:

First question, the @width is relative to what?

I would humbly suggest that image/@width is always relative to the full width of the "page", not the width of the constraining container. For constrained images, the width might then be restricted to min(image/@width, container/@width).

[Andrew Scholer]

I agree that image/@width should be page based. That makes for less confusion if you move an image from one location to another. width="40%" won't change just because you put it in an exercise with some padding or even a sidebyside (assuming there is sufficient space).

I think it also will work better for mobile and other small screens. When an image is set to a small width to avoid looking ridiculous on desktop it often ends up getting way too small on mobile.

For HTML, something like a a calc( ) for width based on --base-content-width coupled with a max-width 100% would probably fit the bill.

[Rob Beezer]

On 2/10/26 11:26, Oscar Levin wrote:
> * An #image in an #exercise in a #sidebyside (in a #worksheet) is not getting

> the sizing info we normally put in the <div class="image-box">.  Presumably
> this could easily be changed to by more careful selection of templates in
> xsl.  Clear to me that we should fix this (it is a bug).

I agree this needs a fix, and I think more careful matching with templates could
provide a cure (maybe the "image-inclusion" mode). Don't forget that a
"regular" #sidebyside can have an #image inside a #stack inside a #sidebyside.
And there are numerous other panels with varying degrees of squishiness. Images
are most easily squished, tables (HTML v. LaTeX) aret he worst. So be sure to
survey those situations.

> * A #sidebyside within an #exercise in a #sidebyside (in a #worksheet) does

> create a sbspanel that gets sized correctly, but CSS has rules for laying
> out a grid of sbspanels, and for some reason a panel in a second exercise
> gets pushed to grid position 2 (which doesn't exist), so the image doesn't
> show up.  Presumably this could be fixed with some more careful css
> selector.  Not sure whether this use case should be supported though.

Supported? Debatable.

The language/syntax of a #sidebyside for layout purposes is recycled into three
distinct uses, as a convenience for authors. "regular" (peer of #p, etc),
worksheet exercises, pieces of a (custom) #interactive.

While a "normal" #exercise should handle a "regular" #sidebyside just fine, it
sounds like mixing a "regular" #sidebyside into a worksheet #sidebyside might be
a bit much, especially for HTML/CSS?

> A larger question that was raised

More later when I have time. But I will remark that it is a conscious design
decision that panels of #sidebyside fill the width allotted by the layout
specifications of the #sidebyside. I recognize that for FIGURE-LIKE some
captions and titles might render in less desirasble ways in extreme cases.

Rob

[Rob Beezer]

On 2/10/26 11:26, Oscar Levin wrote:

> A larger question that was raised by Andrew today was whether an image inside a
> sidebyside should be able to have its own @width specified, so that it could
> fill up just a part of its column (for example, if you wanted the figure to have
> a caption with the width of the sbspanel but the image inside it not.   This
> makes a lot of sense to me, even without a figure present: I want to divide the
> page into two halves, one for an image and one for a table.  I want these to
> both be centered in their own half but not take up the entire space of their
> half.  I suppose I could manage this with margins, but then I'm calculating
> margins and widths to get a specific look, which seems less intuitive.

* I am somewhat sympathetic to "I have a skinny image and I don't like the
skinny caption".

* Control over layout is not very PreTeXt-like. So, for #sidebyside you get
to control the widths of panels, vertical justification within a panel, and
*overall* left and right margins. Then you get equal gaps of whatever space is
leftover. That is a concession to letting an author control layout. (Aside: in
the conversion to braille we totally ignore most of this.)

I am not very sympathetic to Oscar's example of two panels spliting the page
50/50 and then control of width and horizonatal placement of the contents of
each panel. Generally. Though Oscar is right, with only two panels you can get
any two widths, any two margins, and the one gap any way you want already.

* Figures have captions, and the remaining FIGURE-LIKE have titles, which could
become too skinny. A #figure can hold a variety of objects. Will they all
now get a @width attribute? An #image and a #p are squishy (in different ways:
scaling v. word-wrapping. p/@width? (Yes, we do this in cells of a table.)

* I asked: "First question, the @width is relative to what?" If we did have

sidebyside/figure/image/@width

I'd understand the @width to be the fraction of the containing panel's width.
Right now, no @width is 100%. If no specified @width becomes the width of the
panel, it will introduce a lot of logic contrary to have things are done now.

Rob

[Alex Jordan]

Sometimes an image appears in a two-column situation, and then is reused in a one-column situation. For example, an "exercisegroup" is two-column, and an exercise within has an image. So it's certainly two-column in print.

Places where that exercise might be "one-column". For each of these, people might dismiss them as unsupported or out of scope., but I'm lisitng them here anyway.

• the exercise is part of a WeBWorK problem set, and used in WeBWorK
• a "webwork" within the exercise is reused via @copy in a different exercise that is not in a two-column exercisegroup. This happens for me in end of chapter review sets.
• I'm of the opinion to render "two-column" things (especially exercisegroup) as one-column for HTML output. They are only two-column (imho) for the sake of saving paper and avoiding ugly whitespace in print.
• I'm not always sure that when an exercise component is reused in something like a #solutions, honoring the width imposed by the original multicolumn nature of that exercise is good either.

For ORCCA, have various custom things in place for these concerns. My point is, if it's given that the image will be used in these different places, it's a hard question to pin down the meaning of its @width. Be it relative to the immediate container, or relative to the page.

--
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/MTAwMDAxNC5iZWV6ZXI.1770927492%40pnsh.

[Jeremy Sylvestre]

On Thu, 12 Feb 2026 at 13:18, 'Rob Beezer' via PreTeXt development <prete...@googlegroups.com> wrote:

*  I asked: "First question, the @width is relative to what?"  If we did have

sidebyside/figure/image/@width

I'd understand the @width to be the fraction of the containing panel's width.

As an author I am most concerned that the image is sized so that the information presented by this image is "legible" (I don't know the analogous word for an image, sorry). For me, images are usually graphs or diagrams that also contain small bits of text (as labels) or numbers or mathematical symbols. I try to get those images sized so that the size of the text/numbers/symbols within matches the size of the surrounding main text as closely as possible.

The containing panel's width is not a stable enough benchmark against which to try to make that matching happen.

* If I later edit and decide to change exercisegroup/@cols from 3 to 2, I now have to go and redo all my image calculations, just to get my images to display at the same size (in absolute terms) that they did before.

* The width of a knowl-ized <answer> in the structure

exercisegroup/exercise/answer

is not consistent from exercise to exercise. (I don't know if I have a live example to point to at the moment, but I will as soon as I finish and post the Exercises section in chapter 11 of my linear algebra book).

* I might "perfectly" size my image for the main text (bare, not in any kind of container), but then my image might reappear inside a knowl that's inside a sidebyside, say. I would still like my image to appear in the knowl at a size as close to its "original" size as possible, within the constraint of the knowl/sidebyside widths.

I guess from my point of view, an image has an "optimal" size. But most of my images are SVGs generated from TikZ code, and if I don't specify a @width in PreTeXt then my image defaults to full-panel-width.

Ultimately my wish would be that @width could take measurements besides percentage, like pt or em or something, so that as an author I can say "this image should optimally be this size (relative to the surrounding text), but if it needs to be shrunk (as minimally as possible) so that it can fit within some containing structure, then that's OK."

Or, barring that, using the full-panel width as a proxy/benchmark for what "relative to the surrounding text" means is OK too, because PreTeXt aims for a certain number of characters per line, I think?

Cheers,

Jeremy S

[Jeremy Sylvestre]

On Thu, 12 Feb 2026 at 13:55, Alex Jordan <jordanc...@gmail.com> wrote:

• I'm of the opinion to render "two-column" things (especially exercisegroup) as one-column for HTML output. 

Respectfully disagree. I would like students to be able to take in as many of the individual problems in an exercisegroup at a glance as possible, for the following reasons:

1. To pick and choose which problems they want to work on from that group during that homework session, under the philosophy that spaced and varied practise is more effective than massed practise.

2. To be able to reflect on the exercisegroup as a whole, comparing and contrasting between individual problems.

Both of these are more difficult if excessive scrolling is needed to see more of the problems.

 

[Rob Beezer]

Thanks, Alex. That's a good list.

You could add the content of an #xref knowl to the list. Maybe the #xref points
to a figure in a panel of a #sidebyside, and then it gets HUGE in the knowl.

Having said that, shouldn't we be able to alleviate these situations. We know
where an original of something lives (in a column of an #exercisegroup, in a
#sidebyside, ...) and we know where it is going (#solutions, #xref content,
...). Couldn't we develop a scaling transformation from one placement to the other?

Rob

On 2/12/26 12:54, Alex Jordan wrote:
> Sometimes an image appears in a two-column situation, and then is reused in a
> one-column situation. For example, an "exercisegroup" is two-column, and an
> exercise within has an image. So it's certainly two-column in print.
>
> Places where that exercise might be "one-column". For each of these, people
> might dismiss them as unsupported or out of scope., but I'm lisitng them here
> anyway.
>

> * the exercise is part of a WeBWorK problem set, and used in WeBWorK
> * a "webwork" within the exercise is reused via @copy in a different exercise

> that is not in a two-column exercisegroup. This happens for me in end of
> chapter review sets.

> * I'm of the opinion to render "two-column" things (especially exercisegroup)

> as one-column for HTML output. They are only two-column (imho) for the sake
> of saving paper and avoiding ugly whitespace in print.

> * I'm not always sure that when an exercise component is reused in something

> email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> MTAwMDAxNC5iZWV6ZXI.1770927492%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDAxNC5iZWV6ZXI.1770927492%40pnsh>.

>
> --
> 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 <mailto:pretext-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> CA%2BR-jreCx5WLhFHHPG1_i5BcX5iFnr2cnFuchKyDh4O34OSPAw%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/CA%2BR-
> jreCx5WLhFHHPG1_i5BcX5iFnr2cnFuchKyDh4O34OSPAw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.