Feature/side by side objects

[cmhughes]

Hi Rob,
This pull request is subsequent to the discussion started here: https://groups.google.com/forum/#!topic/mathbook-xml-support/-ZWrb-i8ZTE

I'm submitting this quite early for review--it does not yet do all of the things that I want it to do, but before I go too far down the rabbit hole, I'd like to know your thoughts on what I've done so far :)

If you process examples/sample-article.xml with both mathbook-html.xsl and mathbook-latex.xsl you'll see the following output:

html

(The coloured boxes are simply to help me make sure the widths are as I would intend--they'll be removed once this feature is finished.)

LaTeX

I'd mainly like to know if this looks ok to you; I've loaded a couple of packages on the LaTeX side, both from the same author as the excellent caption package (loaded in one of my other pull requests). The html side uses div boxes.

I'll happily receive all feedback, and look forward to adding more to this once I've heard back :)

Best
Chris

[rbeezer]

Dear Chris,

Looks like a great start and I like all the smiling faces. ;-)

Most important: I think the markup in the sample article looks real good. David
F. should like it. I'll have to think of a use for it in my own writing.

Mild cruise through the code, not exhaustive:

Is "\DeclareFloatingEnvironment" from the "float" package? I'd guess so. Your
replacement hard-codes "Figure". Please incorporate that "type-name" template
which allows for some degree of internationalization, such as when you use the
"autoname" feature.

When you are ready, see if you can save with all spaces for indentation, there's
a small mix of tabs. This is critical for chunks of Python/Sage code, so I have
tried to therefore just be consistent throughout the source.

I'll apologize for the obtuse theorem-numbering code. Some day (summer?) I'll
do a better job with that. Hadn't thought about the need to protect the
subfigures from the main numbering.

As usual, thanks for the contributions!

Rob

On 02/15/2015 06:38 AM, cmhughes wrote:

Hi Rob,
This pull request is subsequent to the discussion started here:
https://groups.google.com/forum/#!topic/mathbook-xml-support/-ZWrb-i8ZTE

I'm submitting this quite early for review--it does not yet do all of the things
that I want it to do, but before I go too far down the rabbit hole, I'd like to
know your thoughts on what I've done so far :)

If you process |examples/sample-article.xml| with both |mathbook-html.xsl| and
|mathbook-latex.xsl| you'll see the following output:

|html|
screenshot from 2015-02-15 14 29 30
https://cloud.githubusercontent.com/assets/2224480/6203556/3d0fdc9e-b51f-11e4-843a-3e0a6e683d3f.png

(The coloured boxes are simply to help me make sure the widths are as I would
intend--they'll be removed once this feature is finished.)

|LaTeX|

screenshot from 2015-02-15 14 32 18
https://cloud.githubusercontent.com/assets/2224480/6203566/81eaf362-b51f-11e4-9760-80dae7415373.png

I'd mainly like to know if this looks ok to you; I've loaded a couple of
packages on the |LaTeX| side, both from the same author as the excellent
|caption| package (loaded in one of my other pull requests). The |html| side
uses |div| boxes.

I'll happily receive all feedback, and look forward to adding more to this once
I've heard back :)

Best
Chris

---

    You can view, comment on, or merge this pull request online at:

#52

    Commit Summary

• side by side figures and subfigures in LaTeX and html

• width can be calculated automatically for subfigures

• made sample images better, changed to inline-block for html version

  File Changes
  

• M examples/sample-article.xml
  https://github.com/rbeezer/mathbook/pull/52/files#diff-0 (148)

• M xsl/mathbook-common.xsl
  https://github.com/rbeezer/mathbook/pull/52/files#diff-1 (54)

• M xsl/mathbook-html.xsl
  https://github.com/rbeezer/mathbook/pull/52/files#diff-2 (51)

• M xsl/mathbook-latex.xsl
  https://github.com/rbeezer/mathbook/pull/52/files#diff-3 (71)

  Patch Links:
  

• https://github.com/rbeezer/mathbook/pull/52.patch

• https://github.com/rbeezer/mathbook/pull/52.diff

—
Reply to this email directly or view it on GitHub
#52.

[cmhughes]

Hi Rob,
Thanks for the follow-up :)

Is "\DeclareFloatingEnvironment" from the "float" package? I'd guess so. Your replacement hard-codes "Figure".

In fact, DeclareFloatingEnvironment is from the newfloat package, from the same author as the caption and subcaption packages. I needed to load this, as the original way of declaring a new float wouldn't allow for two captioned floats next to each other.

Please incorporate that "type-name" template which allows for some degree of internationalization, such as when you use the "autoname" feature.

Thanks for pointing this out, sorry for not catching it myself.

When you are ready, see if you can save with all spaces for indentation, there's a small mix of tabs. This is critical for chunks of Python/Sage code, so I have tried to therefore just be consistent throughout the source.

I've re-spaced my chunk of code from sample-article.xml, I hope it's more appropriate.

I plan to test this code a bit more before continuing--for example, you might not like the alignment of the multi-line captions as it currently stands. I'm particularly curious about the div boxes next to each other; I've used inline-block, but wonder if you have a preference....

Best
Chris

[rbeezer]

Thanks, Chris. When you are done, let me know if any float stuff can be
obsoleted/redone so we don't have duplicate packages. Part of my "keep packages
to a minimum" mantra. We should be able to swap packages in/out without authors
ever knowing.

Sorry - I forgot your query about the divs and did not look at them carefully.
David Farmer is a better person to critique the HTML (and he'll want to stay
coordinated there with his SL2X project). I expect he'll be active in the
discussion on this one, so we'll see what he has to say.

Also, hard-coding "style=" is perfectly fine while developing. Long-term we
will want to incorporate these into the CSS, of course. I've done this several
places. We are shooting for reasonably semantic HTML (but practical, still).
Maybe we should make issues (with a tag like css-hard-code) so when we have
(paid) CSS help again we can track progress. Not important at the moment.
Again, David is on top of the CSS.

On 02/15/2015 12:34 PM, cmhughes wrote:

Hi Rob,
Thanks for the follow-up :)

*Is "\DeclareFloatingEnvironment" from the "float" package? I'd guess so. Your
replacement hard-codes "Figure". *

In fact, |DeclareFloatingEnvironment| is from the |newfloat| package, from the
same author as the |caption| and |subcaption| packages. I needed to load this,
as the original way of declaring a new float wouldn't allow for two captioned
floats next to each other.

/Please incorporate that "type-name" template which allows for some degree of
internationalization, such as when you use the "autoname" feature./

Thanks for pointing this out, sorry for not catching it myself.

/When you are ready, see if you can save with all spaces for indentation,
there's a small mix of tabs. This is critical for chunks of Python/Sage code, so
I have tried to therefore just be consistent throughout the source./

I've re-spaced my chunk of code from |sample-article.xml|, I hope it's more
appropriate.

I plan to test this code a bit more before continuing--for example, you might
not like the alignment of the multi-line captions as it currently stands. I'm
particularly curious about the |div| boxes next to each other; I've used
|inline-block|, but wonder if you have a preference....

Best
Chris

—
Reply to this email directly or view it on GitHub
#52 (comment).

[davidfarmer]

I got the message "Your browser is unable to render this SVG image", but I was still able to test it.

In the last example I tried replacing the middle figure by text in "p" tags. It didn't recognize width="33%" on the "p" tag, But if I put the "p" inside a "figure" tag, then it actually looked reasonable.

So it looks like a good start to me. Need to decide what things can go side-by-side:
figure, table, p,... what else?

Some thought is needed on reasonable defaults, such as in the likely case that the widths
specified by the author do not add up to 100%.

I don't think I understand the intent of children="subfigure", or how that would generalize.

[cmhughes]

Hi David,
Thanks for the follow-up.

I got the message "Your browser is unable to render this SVG image", but I was still able to test it.

You need to run the MBX script to update your image directory. For example, I run ./script/mbx -vv -c tikz -f svg -d ~/Documents/projects/openmathdocs/mathbook/examples/images examples/sample-article.xml.

In the last example I tried replacing the middle figure by text in "p" tags. It didn't recognize width="33%" on the "p" tag, But if I put the "p" inside a "figure" tag, then it actually looked reasonable.

Currently that is expected, but I plan to add support for the <p> tag with an [optional] associated width.

So it looks like a good start to me. Need to decide what things can go side-by-side:
figure, table, p,... what else?

These are the only things that I can think of, but am open to other ideas. The <p> tag will allow lists and other elements within it, of course.

Some thought is needed on reasonable defaults, such as in the likely case that the widths
specified by the author do not add up to 100%.

Yes, that's a good point; I should be able to add up the widths that are present, and perform a check.

I don't think I understand the intent of children="subfigure", or how that would generalize.

This allows the (a), (b), (c) that you see in the screenshot above. The other types of children will be subtable which will do analogous numbering for tables.

David, Rob says that you're the person to critique my html--do you have any feedback about the style that I've used to put the figures next to each other? I've used inline-block, do you have a preferred way?

@rbeezer @davidfarmer I plan to update this with support for <p> and <table> within <sidebyside> once we're happy with what I've done so far :)

Best
Chris

[davidfarmer]

Dear Chris,

It may take some iteration to figure out the right way to do the
html. But I do have some initial suggestions.

You have each side-by-side group wrapped in a figure (in both
the xml and the html). That may be reasonable when all the
components are figures, but in general we want something else
in the XML, and probably a div with class="sidebyside"
in the html (or whatever class we decide).

For the components in the side-by-side, we are going to have
a mixture of styling from CSS and styling directly
in the markup (as in style="margin:0; width:13%").

Your suggestion of inline-block sounds reasonable, but
that will be controlled by the CSS for the .sidebyside
class. So you will not need to output that. The CSS will
also include things like

.sidebyside figure { vertical-align: top; }

to give reasonable defaults to the components.

So you will only output a small amount of styling information
(primarily margins and widths?), and put appropriate classes
on each object.

What to you think of the following:

< div class="sidebyside"> ... < /div>

wrapping the whole thing. On each component:

class="left" or class="middle" or class="right"

(with no middle in the case of two things side-by-side).
Each component is either figure, table, or p.

Note: if the side-by-side only contains figures, then I guess
I am okay with having the outermost wrapper be a figure
instead of a div. That makes it easier to put a caption
on the collection.

That should be enough markup to write CSS with reasonable defaults?
There would be selectors like

.sidebyside p.right { }

I can write a first draft of that CSS if people are agreeable to
that markup and you can output the html. I can also contribute
some actual examples I have used in the past.

Regards,

David

On Mon, 16 Feb 2015, cmhughes wrote:

Hi David,
Thanks for the follow-up.

I got the message "Your browser is unable to render this SVG image", but I was still able to test it.

You need to run the MBX script to update your image directory. For example, I run ./script/mbx -vv -c tikz -f svg -d
~/Documents/projects/openmathdocs/mathbook/examples/images examples/sample-article.xml.

In the last example I tried replacing the middle figure by text in "p" tags. It didn't recognize width="33%" on the "p"
tag, But if I put the "p" inside a "figure" tag, then it actually looked reasonable.

Currently that is expected, but I plan to add support for the

tag with an [optional] associated width.

So it looks like a good start to me. Need to decide what things can go side-by-side:
figure, table, p,... what else?

These are the only things that I can think of, but am open to other ideas. The

tag will allow lists and other elements
within it, of course.

Some thought is needed on reasonable defaults, such as in the likely case that the widths
specified by the author do not add up to 100%.

Yes, that's a good point; I should be able to add up the widths that are present, and perform a check.

I don't think I understand the intent of children="subfigure", or how that would generalize.

This allows the (a), (b), (c) that you see in the screenshot above. The other types of children will be subtable which will
do analogous numbering for tables.

David, Rob says that you're the person to critique my html--do you have any feedback about the style that I've used to put
the figures next to each other? I've used inline-block, do you have a preferred way?

@rbeezer @davidfarmer I plan to update this with support for

and

within once we're happy with what
I've done so far :)

Best
Chris

—
Reply to this email directly or view it on GitHub.[AAM6LIQM68NBj3q6KSl5n751spC5ID2Eks5nsi7fgaJpZM4Dgq8J.gif]

[rbeezer]

David had hinted at vertical alignment.

I can see tables of varying height, all with header rows, and it makes sense
then to align their tops at the top of the side-by-side. But maybe a set of
images has contrasting interest at the bottom and you want the alignment the
other way.

Does it make sense for the consituents (image, tabular, p) to react to a
"valign" attribute? I will almost certainly use "valign" in "tabular", and I'd
love to be get as much reuse/consistency as we can out of names like this.

Rob

On 02/16/2015 12:30 PM, davidfarmer wrote:

.sidebyside figure { vertical-align: top; }

[cmhughes]

Hi David, Rob,
Thanks for the follow-ups.

You have each side-by-side group wrapped in a figure (in both the xml and the html). That may be reasonable when all the components are figures, but in general we want something else in the XML, and probably a div with class="sidebyside" in the html (or whatever class we decide).

Yes, indeed--this was as a result of the discussion in https://groups.google.com/forum/#!topic/mathbook-xml-support/-ZWrb-i8ZTE. Are we saying that we want three separate cases:

<figure>
<sidebyside>
 just figures and/or paragraphs
 just figures and/or paragraphs
 just figures and/or paragraphs
</sidebyside>
</figure>

and

<table>
<sidebyside>
just tables and/or paragraphs
just tables and/or paragraphs
just tables and/or paragraphs
</sidebyside>
</table>

and

<sidebyside>
mixture of tables, figures, paragraphs
mixture of tables, figures, paragraphs
mixture of tables, figures, paragraphs
</sidebyside>

What to you think of the following: < div class="sidebyside"> ... < /div> wrapping the whole thing. On each component: class="left" or class="middle" or class="right"

Yep, that sounds reasonable. I'm guessing the left and right classes will float in the html?

Does it make sense for the consituents (image, tabular, p) to react to a "valign" attribute? I will almost certainly use "valign" in "tabular", and I'd love to be get as much reuse/consistency as we can out of names like this.

I certainly think that there is a need for an xml attribute for this; I'd vote in favour of calling it vertical-alignment, as I've read on quite a few different sites that valign is obsolete (in html)--have you both read that as well?

The only thing I'm struggling with on this collaboration is the css--it doesn't seem like it's part of MBX, so other than hard-coding it into the elements like I've done here, how else can I test my work? Should I link to a temporary css file that will be deleted/absorbed into one of the 'official' files?

[davidfarmer]

I have some guesses for default alignments in CSS:

table: top
text next to figure: middle
text next to text: top
figure: ??? that is a tough one. need to look at more examples.

Okay, now I realize that CSS does not let you select every possibility.
But that is okay because the defaults are just there to occasionally
save you some typing.

But maybe you are talking about what to put in the XML to
over-ride the defaults? In that case, "valign" seems like
a good term to re-use.

On Mon, 16 Feb 2015, Rob Beezer wrote:

David had hinted at vertical alignment.

I can see tables of varying height, all with header rows, and it makes sense
then to align their tops at the top of the side-by-side. But maybe a set of
images has contrasting interest at the bottom and you want the alignment the
other way.

Does it make sense for the consituents (image, tabular, p) to react to a
"valign" attribute? I will almost certainly use "valign" in "tabular", and I'd
love to be get as much reuse/consistency as we can out of names like this.

Rob

On 02/16/2015 12:30 PM, davidfarmer wrote:

.sidebyside figure { vertical-align: top; }

—
Reply to this email directly or view it on GitHub.[AAM6LHCOH3wRzOSUmss3rlxJqhQPyCh1ks5nslRzgaJpZM4Dgq8J.gif]

[davidfarmer]

We/you need a CSS file you can use as part of your testing.
Its contents will later become part of the mathbook CSS.

We can do that however you want. My suggestion is that you or I
make a first version which is just barely good enough for you to test
the output of your code. Then I take it and do some polishing and
put it in the public distribution.

Let me know if you want me to do the first version.

As to the XML markup, I have thought less about that, but why
not have < sidebyside> as the outer wrapper? I don't even know
how to think about a sidebyside inside a table. But two tables
inside a sidebyside makes sense to me. You would have to allow
a sidebyside to have a caption.

In other words, your 3rd case contains the first two.

On Mon, 16 Feb 2015, cmhughes wrote:

Hi David, Rob,
Thanks for the follow-ups.

You have each side-by-side group wrapped in a figure (in both the xml and the html). That may be reasonable when all the
components are figures, but in general we want something else in the XML, and probably a div with class="sidebyside" in the
html (or whatever class we decide).

Yes, indeed--this was as a result of the discussion in
https://groups.google.com/forum/#!topic/mathbook-xml-support/-ZWrb-i8ZTE. Are we saying that we want three separate cases:

just figures and/or paragraphs just figures and/or paragraphs just figures and/or paragraphs

and

just tables and/or paragraphs just tables and/or paragraphs just tables and/or paragraphs

and

mixture of tables, figures, paragraphs mixture of tables, figures, paragraphs mixture of tables, figures, paragraphs

What to you think of the following: < div class="sidebyside"> ... < /div> wrapping the whole thing. On each component:
class="left" or class="middle" or class="right"

Yep, that sounds reasonable. I'm guessing the left and right classes will float in the html?

Does it make sense for the consituents (image, tabular, p) to react to a "valign" attribute? I will almost certainly use
"valign" in "tabular", and I'd love to be get as much reuse/consistency as we can out of names like this.

I certainly think that there is a need for an xml attribute for this; I'd vote in favour of calling it vertical-alignment,
as I've read on quite a few different sites that valign is obsolete (in html)--have you both read that as well?

The only thing I'm struggling with on this collaboration is the css--it doesn't seem like it's part of MBX, so other than
hard-coding it into the elements like I've done here, how else can I test my work? Should I link to a temporary css file
that will be deleted/absorbed into one of the 'official' files?

—
Reply to this email directly or view it on GitHub.[AAM6LLbLkGHSL6KXV_IWh8aNjJg0PLxYks5nslgNgaJpZM4Dgq8J.gif]

[rbeezer]

On 02/16/2015 10:30 AM, cmhughes wrote:

/So it looks like a good start to me. Need to decide what things can go
side-by-side:
figure, table, p,... what else?

"figure" and "table" have captions of their own, and (will) contain "image" and
"tabular". (Maybe other things will go into "figure"?). A "paragraph" can have
a title and hold multiple "p".

Might it be possible to recognize the absence/presence of "caption" and "title"
and recognize the nature/desire for subchildren?

Conversely, allow "sidebyside" to also include "image", "tabular", and some
"p"-container, which do not have caption/title information, hence are candidates
for subchildren treatment.

I'm not being 100% clear, but am trying to see how much we can infer from an
author's desire for internal captions versus an over-arching caption, simply by
seeing if the component of the "sidebyside" is dressed up, say as a "table",
rather than just a naked "tabular" (similar for "figure" versus "image").
Paragraphs get trickier if you want several paragraphs to be single unit, or not.

Is the "children" attribute something we can deduce from the organization of the
content of the "sidebyside"? All items of the same type and all caption-less?

The more inspection/computation we can do, the easier the author's job becomes.
This is one of my goals for this project. I'd rather have lots of inference,
perhaps even at a small loss of customizability. The author should not have to
specify what we can infer, and the defaults should provide reasonable output
that can be overridden as necessary/reasonable.

Rob

[cmhughes]

We can do that however you want. My suggestion is that you or I
make a first version which is just barely good enough for you to test
the output of your code. Then I take it and do some polishing and
put it in the public distribution.

It's probably best if you make the first version.

As to the XML markup, I have thought less about that, but why
not have < sidebyside> as the outer wrapper? I don't even know
how to think about a sidebyside inside a table. But two tables
inside a sidebyside makes sense to me. You would have to allow
a sidebyside to have a caption.

In other words, your 3rd case contains the first two.

Yes, this was my initial thought (as you'll see from my first post in the
thread), but then Rob had me change it :)

On Mon, 16 Feb 2015, cmhughes wrote:

Hi David, Rob,
Thanks for the follow-ups.

You have each side-by-side group wrapped in a figure (in both the xml
and the html). That may be reasonable when all the
components are figures, but in general we want something else in the
XML, and probably a div with class="sidebyside" in the
html (or whatever class we decide).

Yes, indeed--this was as a result of the discussion in
https://groups.google.com/forum/#!topic/mathbook-xml-support/-ZWrb-i8ZTE.
Are we saying that we want three separate cases:

just figures and/or paragraphs just figures and/or paragraphs just figures and/or paragraphs

and

just tables and/or paragraphs just tables and/or paragraphs just tables and/or paragraphs

and

mixture of tables, figures, paragraphs mixture of tables, figures, paragraphs mixture of tables, figures, paragraphs

What to you think of the following: < div class="sidebyside"> ... <
/div> wrapping the whole thing. On each component:
class="left" or class="middle" or class="right"

Yep, that sounds reasonable. I'm guessing the left and right classes
will float in the html?

Does it make sense for the consituents (image, tabular, p) to react to a
"valign" attribute? I will almost certainly use
"valign" in "tabular", and I'd love to be get as much reuse/consistency
as we can out of names like this.

I certainly think that there is a need for an xml attribute for this;
I'd vote in favour of calling it vertical-alignment,
as I've read on quite a few different sites that valign is obsolete (in
html)--have you both read that as well?

The only thing I'm struggling with on this collaboration is the css--it
doesn't seem like it's part of MBX, so other than
hard-coding it into the elements like I've done here, how else can I
test my work? Should I link to a temporary css file
that will be deleted/absorbed into one of the 'official' files?

—
Reply to this email directly or view it on
GitHub.[AAM6LLbLkGHSL6KXV_IWh8aNjJg0PLxYks5nslgNgaJpZM4Dgq8J.gif]

—
Reply to this email directly or view it on GitHub
#52 (comment).

[cmhughes]

Is the "children" attribute something we can deduce from the organization
of the
content of the "sidebyside"? All items of the same type and all
caption-less?

I don't believe so. If I can reference my original screenshots, I've got a
few sets of figures next to each other: one of them wants captions that
have (a), (b), (c), one of them wants Figure . next to Figure .. I
can't imagine how this could be inferred from the code without a small
switch (children=....), or have I missed something?

The more inspection/computation we can do, the easier the author's job
becomes.
This is one of my goals for this project. I'd rather have lots of
inference,
perhaps even at a small loss of customizability. The author should not
have to
specify what we can infer, and the defaults should provide reasonable
output
that can be overridden as necessary/reasonable.

Rob

—
Reply to this email directly or view it on GitHub
#52 (comment).

[rbeezer]

On 02/16/2015 01:26 PM, cmhughes wrote:

Yep, that sounds reasonable. I'm guessing the |left| and |right| classes will
|float| in the |html|?

I was guessing that these would be the first and last of "sidebyside" and would
allow for the left and right margins (zero, indents, outdents) of the display to
be specified?

/Does it make sense for the consituents (image, tabular, p) to react to a
"valign" attribute? I will almost certainly use "valign" in "tabular", and I'd
love to be get as much reuse/consistency as we can out of names like this./

I certainly think that there is a need for an |xml| attribute for this; I'd vote
in favour of calling it |vertical-alignment|, as I've read on quite a few
different sites that |valign| is obsolete (in html)--have you both read that as
well?

"valign" would be the MBX attribute (along with "halign"). We get to make them
whatever we want, and do not have to follow HTML. ;-) There is enough
objection to the wordieness of XML that I'd like to keep common attributes short
and meaningful, and avoid multiple words (with hyphens) except for infrequent
things (like "tikz-extra-preamble"). We should spit out "vertical-alignment" in
the HTML and be as compliant/modern as possible. Authors should not have to
know any of this. So "valign" should just work as expected anytime there is a
layout.

The only thing I'm struggling with on this collaboration is the |css|--it
doesn't seem like it's part of |MBX|, so other than hard-coding it into the
elements like I've done here, how else can I test my work? Should I link to a
temporary css file that will be deleted/absorbed into one of the 'official' files?

MBX is the new elemens and attributes, and how they are organized. I want to be
very careful we get that totally right as early in the process as possible. The
converters to HTML and LaTeX are serious efforts, provoke the hard design
questions early, etc. However, anybody can write a new converter (especially if
I am careful about modularity and abstraction for some of the basic stuff).

David (rightly) wants to create very stylable HTML. And I agree entirely. So
our HTML output is designed to rely on CSS in a way so that others could style
(or apply Javascript) in new ways. I think you should definitely hard-code to
test, but also coordinate with David on design of CSS.

Rob

[rbeezer]

On 02/16/2015 01:39 PM, cmhughes wrote:

Yes, this was my initial thought (as you'll see from my first post in the
thread), but then Rob had me change it :)

I must not have been clear, or was misunderstood. ;-)

I've been thinking of "sidebyside" as an outer wrapper.

Feel free to show me where I messed up.

[davidfarmer]

I realize that I should have said that the objects which can
appear in a side-by-side are:

p, paragraph, image, figure, tabular, table

Most of my personal use cases involve the first of each pair,
but most of the examples floating around (pun semi-intended)
have some of the second of each pair.

Rob's sample MBX markup in the Side-by-side thread, on Feb 8, almost
had it the way I would do it, but he changed a p to a paragraph
so that he could title the paragraph.

On Mon, 16 Feb 2015, cmhughes wrote:

Is the "children" attribute something we can deduce from the organization
of the
content of the "sidebyside"? All items of the same type and all
caption-less?

I don't believe so. If I can reference my original screenshots, I've got a
few sets of figures next to each other: one of them wants captions that
have (a), (b), (c), one of them wants Figure . next to Figure .. I
can't imagine how this could be inferred from the code without a small
switch (children=....), or have I missed something?

The more inspection/computation we can do, the easier the author's job
becomes.
This is one of my goals for this project. I'd rather have lots of
inference,
perhaps even at a small loss of customizability. The author should not
have to
specify what we can infer, and the defaults should provide reasonable
output
that can be overridden as necessary/reasonable.

Rob

—
Reply to this email directly or view it on GitHub
#52 (comment).

—
Reply to this email directly or view it on GitHub.[AAM6LJnvCgPvNOeQ7HUIoWmPcyyQF3PNks5nslwOgaJpZM4Dgq8J.gif]

[rbeezer]

On 02/16/2015 01:26 PM, davidfarmer wrote:

But maybe you are talking about what to put in the XML to
over-ride the defaults? In that case, "valign" seems like
a good term to re-use.

Yes, in the XML.

[rbeezer]

On 02/16/2015 01:39 PM, cmhughes wrote:

Yes, this was my initial thought (as you'll see from my first post in the
thread), but then Rob had me change it :)

Maybe I was suggesting "sidebyside" as a wrapper of any variety of items, but
you could wrap that in a "figure". I don't think I was suggesting that the
outermost wrapper would constrain/imply what went into "sidebyside"

Rob

[rbeezer]

On 02/16/2015 01:57 PM, davidfarmer wrote:

Rob's sample MBX markup in the Side-by-side thread, on Feb 8, almost
had it the way I would do it, but he changed a p to a paragraph
so that he could title the paragraph.

It was really to emphasize that multiple paragraphs could be construed as a
single unit, rather tham more than one. The effect would be different. The
title is optional, so would need to appear.

[cmhughes]

Thanks for the follow-ups. I'd like to try and clarify where we're at with this after the very fruitful discussion above--please do feel free to correct me :) Rob, I apologise if I misunderstood you here or in the other thread.

We want the xml to allow for the following:

• the new sidebyside tag wraps around objects which are to be put side-by-side
• these objects, for the moment, are : p, paragraph, image, figure, table
• (I'm not sure why tabular was listed or is needed, but perhaps that's part of the new table vision?)
• the sidebyside tag can be wrapped in either a figure or table tag to allow for a 'global' caption
  • if sidebyside is wrapped in a figure or table then we use < figure class="sidebyside"> ... < /figure> or < table class="sidebyside"> ... < /table>
  • if sidebyside is not wrapped in a figure or table then we use < div class="sidebyside"> ... < /div>
• the sidebyside tag has an attribute that can specify its children as subfigure or subtable to control captions specified as (a), (b), etc
• we want each of the child nodes (specified above as: p, paragraph, image, figure, table, ?tabular?) to have an optional attribute valign that specifies the vertical alignment, and halign that specifies the halign.
  • default value of valign for figures is bottom
  • default value of valign for tables is top
  • default value of valign for p, paragraph, image is center
  • default value of halign is center for every element
  • valign in css actually gets translated vertical-alignment :)

All this being said, is it true to say that the examples I have in the sample-article.xml are how you would like them to be?

As far as next steps go, @davidfarmer could you put together a bare-bones css file that would allow this to be tested? Presumably it would need to include something like the following:

.sidebyside {width:100%; ...}
.sidebyside figure { vertical-align: top; display:inline-block;...}
.sidebyside table { vertical-align: top; }
.sidebyside p ....
.sidebyside image ...
.sidebyside paragraph ....

With this in place, presumably I would remove <xsl:attribute name="style">margin:0;vertical-align:bottom;display:inline-block;text-align:center; from mathbook-html.xsl and replace it simply with checks to see if valign, width, halign are present?

[davidfarmer]

These comments refer to the html:

There can be class="sidebyside" as an attribute to a div or figure
which will contain 2 or 3 side-by-side objects.

Usually it is a div unless you want a caption on the group.

Your list of possible objects is correct, except that "paragraph"
is not a standard html tag, and I also suspect we do not yet have
the proper way to turn an MBX paragraph into html. (That would
involve markup of the title, and a grouping of the contained paragraphs.)

These comments refer to the MBX:

The "sidebyside" tag wraps the 2 or 3 objects to be side-by-side.
Your list of possible objects looks okay for now.

The sidebyside tag is a paragraph level object: it cannot be wrapped
in a figure. It already acts like a "figure" and it can have a caption.

I don't see why the sidebyside tag needs to specify its children
as subfigure or subtable, because those children are what they are.

We need to get straight which layout properties may need to be
specified by the author. That list definitely includes horizontal
alignment, vertical alignment, margins, and width of the component
(as a percent). Need to decide attribute names (as you wrote: halign,
valign, ...

The HTML output will use style="..." to convey the layout information
which was specifically over-ridden by the author. The default values
you wrote are probably the same as what I implemented, but what
will actually happen is that the author will inspect the output
and adjust accordingly.

On Tue, 17 Feb 2015, cmhughes wrote:

Thanks for the follow-ups. I'd like to try and clarify where we're at with this after the very fruitful discussion
above--please do feel free to correct me :) Rob, I apologise if I misunderstood you here or in the other thread.

We want the xml to allow for the following:

• the new sidebyside tag wraps around objects which are to be put side-by-side
• these objects, for the moment, are : p, paragraph, image, figure, table
• (I'm not sure why tabular was listed or is needed, but perhaps that's part of the new table vision?)
• the sidebyside tag can be wrapped in either a figure or table tag to allow for a 'global' caption
• if sidebyside is wrapped in a figure or table then we use < figure class="sidebyside"> ... < /figure> or < table
  class="sidebyside"> ... < /table>
• if sidebyside is not wrapped in a figure or table then we use < div class="sidebyside"> ... < /div>
• the sidebyside tag has an attribute that can specify its children as subfigure or subtable to control captions
  specified as (a), (b), etc
• we want each of the child nodes (specified above as: p, paragraph, image, figure, table, ?tabular?) to have an optional
  attribute valign that specifies the vertical alignment, and halign that specifies the halign.
• default value of valign for figures is bottom
• default value of valign for tables is top
• default value of valign for p, paragraph, image is center
• default value of halign is center for every element
• valign in css actually gets translated vertical-alignment :)

All this being said, is it true to say that the examples I have in the sample-article.xml are how you would like them to
be?

As far as next steps go, @davidfarmer could you put together a bare-bones css file that would allow this to be tested?
Presumably it would need to include something like the following:

.sidebyside {width:100%; ...}
.sidebyside figure { vertical-align: top; display:inline-block;...}
.sidebyside table { vertical-align: top; }
.sidebyside p ....
.sidebyside image ...
.sidebyside paragraph ....

With this in place, presumably I would remove <xsl:attribute
name="style">margin:0;vertical-align:bottom;display:inline-block;text-align:center; from mathbook-html.xsl and replace it
simply with checks to see if valign, width, halign are present?

—
Reply to this email directly or view it on GitHub.[AAM6LK7qQBx6s5eqMraE7k__HpmEodnYks5ns5fYgaJpZM4Dgq8J.gif]

[davidfarmer]

I sent the following in an email, but it didn't appear on this thread. Not sure why.

On this page:

http://aimath.org/~farmer/print/sbs/

I have made a mockup of some content and the associated CSS. Just
look a the source. Note: this is a work in progress and
some of the CSS is not yet working properly.

[rbeezer]

On 02/17/2015 12:11 PM, cmhughes wrote:

Rob, I apologise if I misunderstood you here or in the other thread.

No problem whatsoever - bound to happen (and I'm surprised it is not more often).

• (I'm not sure why |tabular| was listed or is needed, but perhaps that's part
  of the new |table| vision?)

Yes, that will be part of tables. "tabular" will be the guts, perfect for
inclusion in a "sidebyside" with a generated (a), etc. "table" will have a
caption, typically be centered on the page, etc. (tabular is to table as image
is to figure).

More on David's post.

Rob

[cmhughes]

There can be class="sidebyside" as an attribute to a div or figure
which will contain 2 or 3 side-by-side objects.

Usually it is a div unless you want a caption on the group.

Right, sounds good.

The "sidebyside" tag wraps the 2 or 3 objects to be side-by-side.
Your list of possible objects looks okay for now.

I actually think it could be more than 2 or 3; we could potentially have more than that number of figures or tables.

The sidebyside tag is a paragraph level object: it cannot be wrapped
in a figure. It already acts like a "figure" and it can have a caption.

Let's say that you have two figures side by side, with a global caption. You're saying you want the xml to look as follows

<sidebyside>
<figure>
....
</figure>
<figure>
....
</figure>
<caption>global caption</caption>
</sidebyside>

Can you confirm? I'm happy to go implement this; Rob, can you confirm this is how you envisage?

I don't see why the sidebyside tag needs to specify its children as subfigure or subtable, because > those children are what they are.

I guess we could do a check to see if <sidebyside> has a <caption> tag, in which case it's a 'global' caption, and the children are subfigures/subtables? If there is no <caption> tag, then it's assumed that they are as in my screenshot below.

With this in mind, I can see that we could get rid of children, and it sounds like that's the preference.

Yes, that will be part of tables. "tabular" will be the guts, perfect for inclusion in a "sidebyside" with a generated (a), etc. "table" will have a caption, typically be centered on the page, etc. (tabular is to table as image is to figure).

Ok, that makes sense, and should be fine to implement.

http://aimath.org/~farmer/print/sbs/

Awesome, thanks, I'll take a look, make some changes, and report back.

[rbeezer]

On 02/17/2015 01:18 PM, davidfarmer wrote:

These comments refer to the html:

Your list of possible objects is correct, except that "paragraph"
is not a standard html tag, and I also suspect we do not yet have
the proper way to turn an MBX paragraph into html. (That would
involve markup of the title, and a grouping of the contained paragraphs.)

"paragraph" is an inconsistent thing. We mark it up in HTML output like an
unnumbered secton/subsection/subsubsection. I suspect it will behave, but we
should definitely test it.

These comments refer to the MBX:
The sidebyside tag is a paragraph level object: it cannot be wrapped
in a figure. It already acts like a "figure" and it can have a caption.

Lots of things are "peers" of paragraphs and direct descendants of sectioning
divisions. Tables, figures, Sage cells and more. For example, you cannot put
them into list items. So this feels consistent to have "sidebyside" be at the
same level.

I don't see why the sidebyside tag needs to specify its children
as subfigure or subtable, because those children are what they are.

I think this was the source of my not-well-stated question earlier. Is children
supposed to control if two contained figures are "Figure 5.7" and "Figure 5.8"
or if they are "Figure 5.3(a)" and "Figure 5.3(b)"?

Could we distinguish three "figure" inside a "sidebyside" versus three "image"
inside a "sidebyside" and handle captioning/numbering differently?

In any event, I think David and I both need a clearer idea of what "sub-*"
accomplishes that cannot be inferred.

[rbeezer]

On 02/17/2015 01:42 PM, cmhughes wrote:

Let's say that you have two figures side by side, with a global caption. You're
saying you want the xml to look as follows

Can you confirm? I'm happy to go implement this; Rob, can you confirm this is
how you envisage?

I think that looks/sounds good.

I guess we could do a check to see if || has a || tag, in
which case it's a 'global' caption, and the children are
|subfigure|s/|subtable|s? If there is no || tag, then it's assumed that
they are as in my screenshot below.

Are you thinking...:

Global caption gets a number, subitems get an (a), (b), etc with or without a
caption they provide themselves. No global caption and subitems get their own
number and own caption via table, figure, . No global caption and subitems are
naked (tabular, image, ) then they do not get a number nor a caption.

This leaves a subitem that is several paragraphs to be dealt with somehow. The
existing "title" element could play the role of a caption and indicate a desire
for numbering. "paragraph" would just be a way to collect several "p" into one
group. OR, should we think of an analog of figure and table that means "a bunch
of paragraphs that are a display/layout unit". Something like "panel"? It
could be recycled to mean a multi-line content in one cell of a table (which
LaTeX uses a minipage or a parbox for).

With this in mind, I can see that we could get rid of |children|, and it sounds
like that's the preference.

I think that would be good.

Rob

[cmhughes]

I think this was the source of my not-well-stated question earlier. Is children supposed to control if two contained figures are "Figure 5.7" and "Figure 5.8" or if they are "Figure 5.3(a)" and "Figure 5.3(b)"?

Yes, this was the intention. However, bearing in mind the comment below, I can now see that there is no need for it:

Global caption gets a number, subitems get an (a), (b), etc with or without a caption they provide themselves. No global caption and subitems get their own number and own caption via table, figure, . No global caption and subitems are naked (tabular, image, ) then they do not get a number nor a caption.

Yes, exactly. I am confident that subfigure/subtable can be inferred, and the children attribute can be removed.

This leaves a subitem that is several paragraphs to be dealt with somehow. The existing "title" element could play the role of a caption and indicate a desire for numbering. "paragraph" would just be a way to collect several "p" into one group. OR, should we think of an analog of figure and table that means "a bunch of paragraphs that are a display/layout unit". Something like "panel"? It could be recycled to mean a multi-line content in one cell of a table (which LaTeX uses a minipage or a parbox for).

I don't have an opinion on this :)

---

I hope to get to work on this before the weekend, thanks again to you both the feedback, and for the examples. I think I have a clear vision of what you both would like.

[rbeezer]

On 02/17/2015 02:26 PM, cmhughes wrote:

Yes, exactly.

Very good!

Something like "panel"?

I don't have an opinion on this :)

Where is the fun in that? ;-) It is David's construct, so he can have the last
word.

I hope to get to work on this before the weekend, thanks again to you both the
feedback, and for the examples. I think I have a clear vision of what you both
would like.

And I hope it accomplishes what you set out to do in the first place. Thanks
for the explanations and discussion. David and I had talked about this a long
time ago, but it was probably going to be a while before it happened, so I'm
glad to see it shaping up so nicely.

Rob

[davidfarmer]

In a totally separate thread is was asserted that "paragraph" provides
an optional "title" to a collection (of possibly only one)
paragraphs(s), and that it was not numbered.

At the time, "paragraph" served its intended purpose, which was to
allow authors to have something like un-numbered sub-sub-sections
which could go anywhere.

I still think that makes sense in the current context, and we don't
want to have numbers for paragraphs.

Rob took my original side-by-side markup and put a paragraph with
a title like "Step 2". I think it is perfectly reasonable to hard-code
such a title. Having "Step 2" as a automatically numbered object
is just asking for trouble because of the proliferation of special
use cases.

So, I say 'no' to numbers on paragraphs. But we do need better html
markup because currently the title of a paragraph just floats in front
of the first "p" pf the paragraph. We need some type of div
of class "paragraph" with a span in front of the first p
for the title.

  This leaves a subitem that is several paragraphs to be dealt with somehow. The existing "title" element could
  play the role of a caption and indicate a desire for numbering. "paragraph" would just be a way to collect
  several "p" into one group. OR, should we think of an analog of figure and table that means "a bunch of
  paragraphs that are a display/layout unit". Something like "panel"? It could be recycled to mean a multi-line
  content in one cell of a table (which LaTeX uses a minipage or a parbox for).

I don't have an opinion on this :)

---

I hope to get to work on this before the weekend, thanks again to you both the feedback, and for the examples. I think I
have a clear vision of what you both would like.

—
Reply to this email directly or view it on GitHub.[AAM6LPOXKP7GxWrO2vfqterJorPTkWGNks5ns7d_gaJpZM4Dgq8J.gif]

[davidfarmer]

I can provide more html examples, and/or my guess at the corresponding MBX markup.
Just let me know.

[davidfarmer]

What happens when the user specifies widths that total to more than 100
percent?

Maybe just adjust down to 95 percent if the total is more than that?

On Wed, 11 Mar 2015, cmhughes wrote:

I've added the line breaks to the html version; it does cause display issues when the width adds up to 100%, which seems
like a problem.

—
Reply to this email directly or view it on GitHub.[AAM6LAPzy3DbkXrUHowyFq3jW7bjuQAGks5n0IdOgaJpZM4Dgq8J.gif]

[cmhughes]

Thanks for the idea; the width of every sidebyside object is now multiplied by .97 so as to allow some whitespace. What do you think?

[davidfarmer]

Looks good. I don't have any other comments.

On Wed, 11 Mar 2015, cmhughes wrote:

Thanks for the idea; the width of every sidebyside object is now multiplied by .97 so as to allow some whitespace. What do
you think?

—
Reply to this email directly or view it on GitHub.[AAM6LFg5cNqNBd7ZDirLZNfVzz37SfpJks5n0JKtgaJpZM4Dgq8J.gif]

[cmhughes]

Thanks for your time in helping to get the html side working.

I don't have anything else to add to this, but am happy to implement other
changes if you'd like.

On Wednesday, March 11, 2015, davidfarmer notifications@github.com wrote:

Looks good. I don't have any other comments.

On Wed, 11 Mar 2015, cmhughes wrote:

Thanks for the idea; the width of every sidebyside object is now
multiplied by .97 so as to allow some whitespace. What do
you think?

—
Reply to this email directly or view it on
GitHub.[AAM6LFg5cNqNBd7ZDirLZNfVzz37SfpJks5n0JKtgaJpZM4Dgq8J.gif]

—
Reply to this email directly or view it on GitHub
#52 (comment).

[rbeezer]

I'm going to give it a look as soon as I can carve out the time, but have Spring
Break starting in a couple days so it should be very soon.

On 03/12/2015 10:24 AM, cmhughes wrote:

Thanks for your time in helping to get the html side working.

I don't have anything else to add to this, but am happy to implement other
changes if you'd like.

On Wednesday, March 11, 2015, davidfarmer notifications@github.com wrote:

Looks good. I don't have any other comments.

On Wed, 11 Mar 2015, cmhughes wrote:

Thanks for the idea; the width of every sidebyside object is now
multiplied by .97 so as to allow some whitespace. What do
you think?

—
Reply to this email directly or view it on
GitHub.[AAM6LFg5cNqNBd7ZDirLZNfVzz37SfpJks5n0JKtgaJpZM4Dgq8J.gif]

—
Reply to this email directly or view it on GitHub
#52 (comment).

—
Reply to this email directly or view it on GitHub
#52 (comment).

[rbeezer]

Thanks very much, Chris. Nicely done. This will be a valuable addition. And
thanks to David for the HTML/CSS work.

Merged, with some minor editorial work on the commit messages. I should have
some basic tables soon, and then we can see how the tables slide in.
Announcement in a minute.

What next? ;-)

Rob

On 03/12/2015 10:24 AM, cmhughes wrote:

I don't have anything else to add to this, but am happy to implement other
changes if you'd like.

[cmhughes]

Awesome, thanks very much for accepting it :) I hope it will be a useful
feature for others! I appreciate the feedback and time that you and
@davidfarmer have provided.

Best
Chris

On Fri, Mar 13, 2015 at 4:51 AM, Rob Beezer notifications@github.com
wrote:

Thanks very much, Chris. Nicely done. This will be a valuable addition.
And
thanks to David for the HTML/CSS work.

Merged, with some minor editorial work on the commit messages. I should
have
some basic tables soon, and then we can see how the tables slide in.
Announcement in a minute.

What next? ;-)

Rob

On 03/12/2015 10:24 AM, cmhughes wrote:

I don't have anything else to add to this, but am happy to implement
other
changes if you'd like.

—
Reply to this email directly or view it on GitHub
#52 (comment).

[cmhughes]

Two small issues have come to light with this feature: one of them is LaTeX is related (which can be fixed easily) and one of them is html related (which will rely upon David's CSS magic).

• in LaTeX version, a 'naked' <p> is getting processed twice, so cross references and mathematical content are not rendered correctly (this can be fixed easily)
• in html a 'naked' <p> does not get aligned side-by-side.

The following snippet demonstrates both of these, which can be pasted into sample-article.xml

          <sidebyside>
            <p valign="middle">here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text;  cross reference: <xref autoname="yes" ref="text-next-to-figure"/></p>
              <figure width="20%" valign="top" xml:id="text-next-to-figure">
              <image source="images/trefoil.png" height="30" />
              <caption>Text next to a figure</caption>
              </figure>
          </sidebyside>

My question is: now that sidebyside has been merged into dev, how would you like me to fix this? Would you like me to submit a new pull request, or to rebase this branch onto dev so that sidebyside is back at the tip? Or something different? My sincerest apologies for the LaTeX part of this, and for not pushing the naked <p> far enough.

[rbeezer]

Dear Chris,

No problem. Just make a branch with the necessary changes off wherever the tip
of dev is at the moment. I can rebase on the tip when I merge, if necessary.

If the extensive examples in th sample document don't flex these items, feel
free to adjust or add something to catch/test the subtleties (such as yor
snippet below).

Thanks,
Rob

On 03/16/2015 03:10 PM, cmhughes wrote:

Two small issues have come to light with this feature: one of them is LaTeX is
related (which can be fixed easily) and one of them is html related (which will
rely upon David's CSS magic).

• in |LaTeX| version, a 'naked' |

  | is getting processed twice, so cross
  references and mathematical content are not rendered correctly (this can be
  fixed easily)

• in |html| a 'naked' |

  | does not get aligned side-by-side.

The following snippet demonstrates both of these, which can be pasted into
|sample-article.xml|

|

here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text here is some text; cross reference:

Text next to a figure


|

My question is: now that |sidebyside| has been merged into |dev|, how would you
like me to fix this? Would you like me to submit a new pull request, or to
rebase this branch onto |dev| so that |sidebyside| is back at the tip? Or
something different? My sincerest apologies for the |LaTeX| part of this, and
for not pushing the |naked

| far enough.

—
Reply to this email directly or view it on GitHub
#52 (comment).

[davidfarmer]

I fixed the CSS for the naked "p" in a sidebyside. No need to do
anything else. Reload to verify.

On Mon, 16 Mar 2015, cmhughes wrote:

Two small issues have come to light with this feature: one of them is LaTeX is related (which can be fixed easily) and one
of them is html related (which will rely upon David's CSS magic).

• in LaTeX version, a 'naked'

  is getting processed twice, so cross references and mathematical content are not
  rendered correctly (this can be fixed easily)

• in html a 'naked'

  does not get aligned side-by-side.

The following snippet demonstrates both of these, which can be pasted into sample-article.xml

      <sidebyside>
        <p valign="middle">here is some text here is some text here is some text here is some text here is some text he

re is some text here is some text here is some text here is some text here is some text here is some text here is some text
here is some text here is some text here is some text here is some text here is some text here is some text here is some t
ext here is some text here is some text; cross reference:

Text next to a figure

My question is: now that sidebyside has been merged into dev, how would you like me to fix this? Would you like me to
submit a new pull request, or to rebase this branch onto dev so that sidebyside is back at the tip? Or something different?
My sincerest apologies for the LaTeX part of this, and for not pushing the naked

far enough.

—
Reply to this email directly or view it on GitHub.[AAM6LKL-iGzo6SRXG-oKmK8U_i1AhHsyks5n10xggaJpZM4Dgq8J.gif]

[rbeezer]

Finished up basic tables today and put tiny placeholder tables into the side-by-side. That seems to have exposed some bugs.

In a template for sidebyside/tabular there is an <xsl:apply-templates /> which I think will just process the guts of a tabular (by-passing the outer element). Try <xsl:apply-templates select="."/> and you go recursive forever. I just learned that <xsl:apply-imports /> will call the more general template from within the more specific one (I use this all the time when importing stylesheets). At about line 2280 of mathbook-latex.xsl.

The last four tabulars seem to throw several warnings each (commenting them out right now), and then so do some of the others. Using "apply-imports" definitely helps, but still there are some warnings. Put an xsl:message inside the generic "tabular" template to get a feel for what's going on. Try making the other tabulars into one-row one-cell tables and some more warnings will arise.

I figure you have a better idea of what should be happening, but let me know if you want me to pursue this some more.

[cmhughes]

@rbeezer @davidfarmer I've updated this branch to account for the (now present) tabular elements. I apologise that they didn't initially work--my only defense is that the tabular element didn't actually exist at the time of testing!

A couple of CSS vertical alignment issues remain in Sections 22.11 and 22.12; @davidfarmer if you have a chance to look at them, I'd be most grateful.

[rbeezer]

Dear Chris,

Thanks for doing all the tables (I was prepared to do that myself). Definitely bad practice for both of us to let side-by-side tables go in before tables were done, but I knew the risks. I'm not done looking, but had one big question for now. No rush, I may come back and tinker some more later and get it straight in my head myself.

I see name="tabular" on <tabular>.

<xsl:template match="tabular" name="tabular">

and a call/use at

<xsl:call-template name="tabular" select="self()" />.

Can you educate me on that device? And what happens if we later have

<xsl:template match="tabular" name="tabular-two">

Every place a generic <apply-templates /> hits a tabular, which of these two templates will be employed?

Earlier I could get <apply-imports /> to seemingly accomplish the necessary template to be applied, but now I can't get that going.

Rob

[cmhughes]

Hi Rob,
Thanks for the follow-up.

Can you educate me on that device? And what happens if we later have

           <xsl:template match="tabular" name="tabular-two">

Every place a generic hits a tabular, which of these two templates will be employed?

My understanding is that the latest template (in the xsl) will get applied in this instance. As you described previously, using <xsl:apply-templates select="."/> sends us into an infinite loop, so my intention in using the name=tabular was to call that specific template. I tried a few things with apply-imports, but didn't have any success. I'm very happy to hear more about this and other options, as my implementation may not be optimal. I'm very happy to work on any other feedback that you might have.
Best
Chris

[davidfarmer]

The vertical alignment in 22.11 and 22.12 (which I think are now 22.10 and 22.11) is being completely
controlled by the style="..." which is written into the HTML: there is no CSS involved.

I agree that things are not appearing as intended, and my current theory is that this is due to
bugs and/or unavoidable odd behavior when trying to have a variety of top/middle/bottom
alignments of blocks with various sizes. For example, you would think it doesn't matter if you
set the vertical-align on the tallest item, because it is just going to span the available vertical
space. But it appears that does matter.

For example, in the table - text - text example, where the table is short and the text in the
middle is tall, setting top - middle - middle does what I think it should, but setting
top - top - middle, which ought to result in the exact same appearance, looks like what
you might expect from top - top - top.

Not sure there is anything to do about it now, except maybe put a warning in the sample
document so authors know to try apparently equivalent markup.

[rbeezer]

Dear Chris,

Yes, I think you are right about the order. I've been trying to avoid having template order have anything to do with which template gets used, that sounds like a nightmare maintenance problem long-term. (Though there may be a place where I did this long ago.) I do regularly use "apply-imports" to override base templates in specialized converters based on importing general stylesheets into specific ones - that works like a charm. I re-read the post about apply-imports, so I think I was mistaken about being able to use that here. (XSLT 2.0 has "next-match" which would be perfect, I think.)

If the following sounds feasible would you be willing to give it a try?

1. Split off the "sidebyside" template from "figure" to be its own template.
2. Do any setup, wrapup here in this template (eg seems like something happens after the last sub-item with your stack?).
3. In between have <xsl:apply-templates select="." mode="sidebyside" />
4. Bust out your template matching sidebyside/figure|sidebyside/table|sidebyside/image|sidebyside/tabular|sidebyside/paragraphs|sidebyside/p into 6 modal templates like <xsl:template match="tabular" mode="sidebyside" /> where you can do any setup, wrapup (widths, alignments) and then have <xsl:apply-templates select="." />
   in the middle that will do the generic stuff that already exists. For example, then I think this would allow you to go back from the "processImage" device. The advantage is that if something new goes in, both as regular stuff and as sidebyside stuff, then a new modal template with mode="sidebyside" should just slot in properly.
5. Now, the 6 templates would have lots of common code, but you can define modal templates for the repetitive parts, like
   <xsl:template match="*" mode="sub-item-halign>
   that would set the raggged right, etc based on the attribute on the item. You can see some of this in the code for tables where I have some "utility" functions near the bottom of the main routines.
6. Where you have big conditionals now, that stuff would just go in the corresponding modal templates.

In short, I use modal templates a lot like I am doing object-oriented programming.
<xsl:template match="foo" mode="bar" /> feels to me like foo.bar(), though foo is more like class than an instance variable. And of course they can be parameterized.

Rob

[cmhughes]

Hi Rob,
Thanks for the follow-up; I apologise for my delayed response (busy at work, etc etc).

I believe that I have incorporated the feedback you provided above into my branch; I can see why you like this approach, it is really quite clean. I hope I have implemented as you would like and I'm happy to make further modifications if you'd like.

Best
Chris

[Alex-Jordan]

Hi Chris,

I'm still working on the implementation of sidebyside that was pulled earlier. I'm having an issue where images (not in figures) that are produced in a sidebyside are duplicated. It's like the templates within the image are being applied twice. This is happening for latex-image-code images, not images from files. Here is some code where this is happening. Would you check if this is happening on the branch you are working on? It may not be an issue with your current work.

This code should be making three side by side blank graphs, but instead it is making 6. The .tex output indicates each image is repeated. (It's too hard to tell from the pdf since the images partially overlap and run off the page.)

            <sidebyside>
                <image width="30%">
                    <latex-image-code>
                    <![CDATA[\begin{tikzpicture}
                    \begin{axis}[xmin = -7,
                                 xmax = 7,
                                 ymin = -7,
                                 ymax = 7,
                                 xtick = {-6,-4,...,6},
                                 ytick = {-6,-4,...,6},
                                 minor xtick = {-7,-6,...,7},
                                 minor ytick = {-7,-6,...,7},
                                 width=\linewidth,]
                    \end{axis}
                    \end{tikzpicture}]]>
                    </latex-image-code>
                </image>
                <image width="30%">
                    <latex-image-code>
                    <![CDATA[\begin{tikzpicture}
                    \begin{axis}[xmin = -7,
                                 xmax = 7,
                                 ymin = -7,
                                 ymax = 7,
                                 xtick = {-6,-4,...,6},
                                 ytick = {-6,-4,...,6},
                                 minor xtick = {-7,-6,...,7},
                                 minor ytick = {-7,-6,...,7},
                                 width=\linewidth,]
                    \end{axis}
                    \end{tikzpicture}]]>
                    </latex-image-code>
                </image>
                <image width="30%">
                    <latex-image-code>
                    <![CDATA[\begin{tikzpicture}
                    \begin{axis}[xmin = -7,
                                 xmax = 7,
                                 ymin = -7,
                                 ymax = 7,
                                 xtick = {-6,-4,...,6},
                                 ytick = {-6,-4,...,6},
                                 minor xtick = {-7,-6,...,7},
                                 minor ytick = {-7,-6,...,7},
                                 width=\linewidth,]
                    \end{axis}
                    \end{tikzpicture}]]>
                    </latex-image-code>
                </image>
            </sidebyside>

[rbeezer]

I tested Chris' new work and the old stuff was giving me duplicates and the new
was not. So your problem may be gone. I may test more tonight.

Rob

On 04/02/2015 04:21 PM, Alex Jordan wrote:

Hi Chris,

I'm still working on the implementation of |sidebyside| that was pulled earlier.
I'm having an issue where images (not in figures) that are produced in a
|sidebyside| are duplicated. It's like the templates within the |image| are
being applied twice. This is happening for |latex-image-code| images, not images
from files. Here is some code where this is happening. Would you check if this
is happening on the branch you are working on? It may not be an issue with your
current work.

This code should be making three side by side blank graphs, but instead it is
making 6. The |.tex| output indicates each image is repeated. (It's too hard to
tell from the pdf since the images partially overlap and run off the page.)

|
















|

—
Reply to this email directly or view it on GitHub
#52 (comment).

[rbeezer]

Never any rush, at all. Code looks good. I'm going to have another look right now.

Seems we have one small problem, I think. If so, my fault. A "tabular" can
have an "halign" attribute. I want to use it for global alignment inside cells,
and I think you want to use it to align within the sidebyside. It is no problem
if the tabular is inside a "table". It was my idea to use halign for two
similar purposes.

Am I right? Any ideas for a fix?

Rob

On 04/01/2015 09:56 AM, cmhughes wrote:

Hi Rob,
Thanks for the follow-up; I apologise for my delayed response (busy at work, etc
etc).

I believe that I have incorporated the feedback you provided above into my
branch; I can see why you like this approach, it is really quite clean. I hope I
have implemented as you would like and I'm happy to make further modifications
if you'd like.

Best
Chris

—
Reply to this email directly or view it on GitHub
#52 (comment).

[rbeezer]

Merged. Much cleaner. Thanks for working through that.

Alex - try now.

[Alex-Jordan]

I can confirm it's working without the earlier repetition. Thanks!

[cmhughes]

Thanks for reviewing and merging this, I'm glad it has fixed the
duplication problems.

Regarding the halign issue; I'm not sure that the sidebyside value has
much/any effect, as tabulars sit snuggly inside of a box. Can you see any
places that produce a conflict?

On Friday, April 3, 2015, Alex Jordan notifications@github.com wrote:

I can confirm it's working without the earlier repetition. Thanks!

—
Reply to this email directly or view it on GitHub
#52 (comment).