Side-By-Side Groups

[Robert Beezer]

Authors,

I've refactored the common routines for side-by-side layout, as a prelude to fixing some shortcomings with placing various objects inside.  No output was harmed, according to my tests, though I did not check the error-handling bits.  (@Alex - "common-setup" is gone and a proper template is in -common for use in any conversion.  Interface to four specialized routines has not changed.  "compose-panels" template has one change, you can infer it from the changes to -latex and -html in the commit.  I might still try to unwind some of the recrusion there, but that may have zero impact.)

Done right, you will not notice, but we have better modularization, clearer code, more robust error checks.

Also, some "problems" with side-by-side groups have gone away.  Specifically, they can't have an overall caption now, so that problem goes away.  For sure, sub-captioning will be erratic still.  However, the schema is now correct and implementation will catch up.  Two non-stressful examples are in the sample article (which have always been there) with no changes and new lead-in commentary.  Look there for details.

@Alex - was it Carly that was after this?  Can you alert her?

Thanks,
Rob

[Rob Beezer]

Really just for Alex. I've done some clean-up on "sidebyside" so the layout
parameters are easy to get at, and the rest has no recursion.

Recall there is a row of "headings" (titles), a row of main content, a row of
captions.

It might now be possible to go in a column-major fashion: heading, content,
caption for each panel, repeatedly.

1. That would be better for screen readers, no?

2. You also find the LaTeX "savebox" to be in the way. IIRC, this is entirely
so we know how tall the tallest "content" box is, and likely also so we can get
vertical alignment right. If you see a way clear to do it different (without
LaTeX packages emulating a stack!) it might be time to rethink.

Any change in approach will need to have the same overall strategy (like rows
first, columns first) for both LaTeX and HTML.

Not at all urgent, and not something I can hop in on right away anyway.
Long-term planning. Keep notes.

Rob

[Alex Jordan]

1.  That would be better for screen readers, no?

That's right. Encounter title, image, caption; title, image caption. Not title, title;
image, image; caption, caption.
 

2.  You also find the LaTeX "savebox" to be in the way.  IIRC, this is entirely
so we know how tall the tallest "content" box is, and likely also so we can get
vertical alignment right.  If you see a way clear to do it different (without
LaTeX packages emulating a stack!) it might be time to rethink.

It's possible that \savebox might be OK. I notice it is used without using the
optional width argument, and it occurs to me that maybe that can be used to
address my concern. When I get these other things off my list...
 

[Rob Beezer]

On 07/31/2017 09:52 PM, Alex Jordan wrote:
> It's possible that \savebox might be OK.

Sounds promising. No rush at all - keep it on the back burner.

[Robert Beezer]

The sample article now has three examples of "sbsgroup", each with twelve copies of an identical test image, packed into figures in three "sidebyside".  The first two have everything line up nicely with just one attribute given on the overall "sbsgroup".  The third tests local overrides, so makes a mess.

With no enclosing figure, the captions of the twelve figurews get the right numbers with no new code (I love it when that happens!).  With an enclosing figure, as suspected, there is no subcaptioning at all.  Working on it.

So the schema is accurate, and you can start using this - just be aware that subcaptions *will* happen soon and then numbering of subsequent items will all change.  So not "production ready."

http://mathbook.pugetsound.edu/examples/sample-article/html/section-side-by-side.html#subsection-47

Rob