search

PreTeXtBook / pretext

PreTeXt: an authoring and publishing system for scholarly documents
https://pretextbook.org
Other
254 stars 203 forks source link

Feature/side by side objects #52

Closed cmhughes closed 9 years ago

cmhughes commented 9 years ago

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

(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

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 commented 9 years ago

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:

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

    Commit Summary

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/pull/52.

cmhughes commented 9 years ago

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 commented 9 years ago

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 https://github.com/rbeezer/mathbook/pull/52#issuecomment-74435430.

davidfarmer commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/rbeezer/mathbook/pull/52#issuecomment-74575941.

cmhughes commented 9 years ago

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 https://github.com/rbeezer/mathbook/pull/52#issuecomment-74576363.

rbeezer commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/rbeezer/mathbook/pull/52#issuecomment-74576363.

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

rbeezer commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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:

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.

screenshot from 2015-02-17 21 35 37

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

cmhughes commented 9 years ago

Hi Rob and Dave, The latest commit allows sidebyside Figures (numbered and sub-numbered), images, and text blocks in html. Each one can have different horizontal and vertical alignment. You'll also see that the children attribute has been removed--hoorah!

For the moment, I haven't implemented this in LaTeX, but I'm not worried about that at all (cross referencing is trivial, and it's just a matter of working with minipage and friends).

You'll see that the sample-article.xml contains a number of different examples. I hope that this is going in the right direction for you both, please do let me know your comments/questions/concerns.

I'd be very grateful for your feedback on the html side of things. David, I used the template that you posted here (http://aimath.org/~farmer/print/sbs/) as a guide. The only thing that I think is missing from your css file is the ability to handle <figcaption> from within <sidebyside> which is why it isn't rendering correctly (as bold).

Once the current stuff with figures has been reviewed, I'll do it all for tables. If you'd prefer me to do the tables at the same time, please do let me know.

Best Chris

davidfarmer commented 9 years ago

Dear Chris,

Looks really good! It was a great end of my week to see all the examples working so well.

If you reload the html you will see "Figure 21.1." in bold in the captions. I need to do some more work on the captions to get the spacing a bit nicer. (I did not yet copy over all of the CSS from figures.)

I don't think the div with "clear:both" does anything, so it should be deleted.

Am I correct that you don't currently have a way to make a wider gap between objects (such as more space between the text and Figure 21.10)?

Rob is working on tables this weekend, but I am not sure if that has any bearing on incorporating tables into side-by-side. (Rob: it probably will be tomorrow before I get to the new table CSS.)

Regards,

David

On Fri, 20 Feb 2015, cmhughes wrote:

Hi Rob and Dave, The latest commit allows sidebyside Figures (numbered and sub-numbered), images, and text blocks in html. Each one can have different horizontal and vertical alignment. You'll also see that the children attribute has been removed--hoorah!

For the moment, I haven't implemented this in LaTeX, but I'm not worried about that at all (cross referencing is trivial, and it's just a matter of working with minipage and friends).

You'll see that the sample-article.xml contains a number of different examples. I hope that this is going in the right direction for you both, please do let me know your comments/questions/concerns.

I'd be very grateful for your feedback on the html side of things. David, I used the template that you posted here (http://aimath.org/~farmer/print/sbs/) as a guide. The only thing that I think is missing from your css file is the ability to handle

from within which is why it isn't rendering correctly (as bold).

Once the current stuff with figures has been reviewed, I'll do it all for tables. If you'd prefer me to do the tables at the same time, please do let me know.

Best Chris

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

cmhughes commented 9 years ago

Hi David, Thanks very much for the encouragement, I'm glad it's looking good from your end. Likewise, it has ended my week very well to hear positive feedback from you, and I appreciate your time in reviewing this.

I can confirm that the Figure captions are now bold in sidebyside, thanks for doing that; I have also removed the div that had clear:both, it was an artifact of my previous css adventures.

Am I correct that you don't currently have a way to make a wider gap between objects (such as more space between the text and Figure 21.10)?

Could you clarify this a little more, i.e, do you mean horizontal or vertical space?

Rob is working on tables this weekend, but I am not sure if that has any bearing on incorporating tables into side-by-side. (Rob: it probably will be tomorrow before I get to the new table CSS.)

It's very doubtful that this will affect any of sidebyside. I'm mainly waiting just so that I don't have to go back and change too many things. Once I've got the all-clear from you and Rob, I'll finish this off with the tables and the LaTeX version.

Best Chris

rbeezer commented 9 years ago

Dear Chris,

Looking very good! A few nits below.

I'd like to have both HTML and LaTeX output in place together for any new feature before merging. If you want to wait and do tables on another branch that is fine. And we'll want to make sure "textblock" is finalized (see below) before putting it out in the sample article.

I am confident "table" will have a "caption" and "tabular" will be the caption-less guts. What comes after that is still a bit in flux.

Thanks for this, it will be a very nice addition.

Rob

sample-article.xsl

Code:

cmhughes commented 9 years ago

Hi Rob, Thanks for the follow-up.

I'd like to have both HTML and LaTeX output in place together for any new feature before merging.

Certainly, and I wouldn't have it any other way. I was just waiting on this branch to see if you and David were happy so far. I'll get going on tables and the LaTeX version immediately, it will be a complete part of this branch.

Thanks for the feedback on those issues, I'll get to work on them.

Do you like "textblock" or is it a place-holder? Will "paragraph" work or does that feel wrong? In any case, can the author subdivide this by "p"?

I'm happy to use paragraph. If you'd like the author to be able to subdivide it into multiple <p> elements then we'll need @davidfarmer to adjust the css a little bit; David, would it be appropriate to have <paragraph width=xxx> map to its own <paragraph> element in html?

Is "textblock" like "figure" or like "image" (or neither)?

textblock, figure, image, and (in a few days) table, tabular will all be allowed to be placed within sidebyside.

I'll hope to be able to work on this in the next few days. As we've discussed in other threads/e-mails, some git rearranging will probably need to happen to organise the commits.

Thanks again to both. Chris

davidfarmer commented 9 years ago

Chris: I would like the option of more horizontal space between the words and Figure 21.10. It isn't critical to add that feature now, as long as we aren't doing anything to make it harder later.

I am not certain of the right way to specify horizontal spacing and margins in the MBX of a side-by-side, nor am I certain of the best way to do that in the html. Any suggestions would be welcome.

Rob: valign="middle" is the current standard. People have put reasonable thought into the topic and I agree with that choice. We can discuss if you wish.

Rob: are your "textblock" questions related to the "paragraph" environment? I have been thinking of paragraph as being like figure and p as being like image. I have some thoughts on the html and css for paragraph and could do a mockup if that will help.

Do you like "textblock" or is it a place-holder? Will "paragraph" work or does that feel wrong? In any case, can the
author subdivide this by "p"?
  • Is "textblock" like "figure" or like "image" (or neither)?
rbeezer commented 9 years ago

On 02/21/2015 03:22 PM, davidfarmer wrote:

Rob: valign="middle" is the current standard. People have put reasonable thought into the topic and I agree with that choice. We can discuss if you wish.

"middle" is just fine. I was basically wondering if "reasonable thought" had gone into it and what the outcome was. Thanks.

Rob: are your "textblock" questions related to the "paragraph" environment? I have been thinking of paragraph as being like figure and p as being like image. I have some thoughts on the html and css for paragraph and could do a mockup if that will help.

Exactly. We have "figure" containing "image", and "table" will contain "tabular". In each pair the former has a caption and the latter is just the guts. "sidebyside" reacts to each part of the pair differently. So I think my questions are:

  1. Can we have "paragraph" and (multiple) "p" be a similar pair? "paragraph" already admits a "title", we could perhaps have it admit a caption when inside "sidebyside" (along with preserving the use of "title"?).
  2. Is it a problem to have "paragraph" be a subsubsubsubsection usually and more of a container in sidebyside? Would we be asking too much of one name (I'd be nice if the answer is no, I'd like to recycle names in natural ways)?
  3. So my question about "textblock" was/is: is "textblock" a container/wrapper or the guts? And if so, what is paired with it? If we are adding a new element to this setting (not against, depending on answers to 1 and 2), I'd want to be certain just how it is intended. I could not answer that question myself from the sample article use.

Rob, slowly going mad learning too much about LaTeX table packages

cmhughes commented 9 years ago

Thanks very much for the follow-ups.

Chris: I would like the option of more horizontal space between the words and Figure 21.10. It isn't critical to add that feature now, as long as we aren't doing anything to make it harder later.

Do you mean between Figure 21.10 and the body of the caption? Is this an XML thing, or a CSS thing?

  1. Can we have "paragraph" and (multiple) "p" be a similar pair? "paragraph" already admits a "title", we could perhaps have it admit a caption when inside "sidebyside" (along with preserving the use of "title"?).

Yes, this sounds good. My current mark-up (not pushed yet) has 

<paragraph>
<p> text text text</p>
<p> text text text</p>
<p> text text text</p>
</paragraph>

This allows a 'textblock'/'panel'/'tile' with multiple paragraphs to be next to a figure/image/table/tabular/text.

Is this how you would want it?

@davidfarmer I'm working on the implementation of table and tabular; please can you add support for each of the following elements in sidebyside to your math-add-on.css:

Many thanks for your time.

davidfarmer commented 9 years ago

I want:

block of words more space image

And more generally a way to adjust the spaces between the parts in a side-by-side. But let's talk about options first, because there is going to be some tension between flexibility and ease of use in the MBX. And I don't know how to choose between different options in the html/css.

I added some CSS for table and tabular, but I may have missed something.

I don't want to add anything for paragraph yet because I think we don't know enough yet about how to mark up a paragraph. I'd even like to reconsider the term "paragraph", since it does not accurately describe what it contains. I'll send a message to the group about that.

On Sun, 22 Feb 2015, cmhughes wrote:

Thanks very much for the follow-ups.

  Chris: I would like the option of more horizontal space between the words and Figure 21.10. It isn't critical
  to add that feature now, as long as we aren't doing anything to make it harder later.

Do you mean between Figure 21.10 and the body of the caption? Is this an XML thing, or a CSS thing?

   1. Can we have "paragraph" and (multiple) "p" be a similar pair? "paragraph" already admits a "title", we
      could perhaps have it admit a caption when inside "sidebyside" (along with preserving the use of "title"?).

Yes, this sounds good. My current mark-up (not pushed yet) has

text text text

text text text

text text text

This allows a 'textblock'/'panel'/'tile' with multiple paragraphs to be next to a figure/image/table/tabular/text.

Is this how you would want it?

@davidfarmer I'm working on the implementation of table and tabular; please can you add support for each of the following elements in sidebyside to your math-add-on.css:

  • paragraph
  • table
  • tabular
  • .sidebyside > table > figcaption

Many thanks for your time.

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

rbeezer commented 9 years ago

Librarians here tell me that all of these things going into sidebyside (perhaps just when un-captioned) are called "text figures". Best I could do for actual chunks of text laid out next to an illustration is a "text frame", which would really be a widget in a desktop publishing application.

But maybe a "paragraphs" element will serve as a good container for multiple "p" (and friends).

cmhughes commented 9 years ago

Hi Rob and Dave, I think this is ready for another review; both LaTeX and html can now support any combination of the following objects side-by-side:

If you run the sample-article.xml through both translation scripts, you should see a complete demonstration, including cross references in both LaTeX and html.

I believe that I have incorporated all of the feedback you've provided (and thank you again); I look forward to other feedback.

I'll re-jig the commits (not sure how to do that yet) if we get to a point where this is ready to be accepted. Best Chris

rbeezer commented 9 years ago

Dear Chris,

Looking real good. A few things from looking carefully.

Rob

davidfarmer commented 9 years ago

I saw a few things:

The html references to figures and tables are hyperlinks, not knowls.

In Section 21.9 you say that you can't put a global caption when there is a table next to a figure. But if you do it, it works just fine. If you put the caption at the beginning of the sidebyside then it goes above, and if you put it at the end, it goes below. That is a useful and desirable feature, so why can't we have that for figures in general? (In particular, there are times when one might want to globally caption a sidebyside with different types of sub-objects.)

When you have tables next to each other, I think the global caption should be called a "Figure" because the global object is not a table: it is a collection of tables. I am suggesting that the global caption of a sidebyside is always called a "Figure".

In some of the examples it would be good to have a "p" not "paragraphs" in the sidebyside, and it would be good to put a "title" on some of the paragraphs. (When I put a p by itself, the valign attribute got lost.)

In Section 21.4 you say that the default valign is bottom, but currently that is not true. There are different defaults in different situations and for different types of objects. I'd like to understand what is the best way to handle that.

This may be someone else's problem, but paragraphs are being converted in html to "figure" not "article, and the title is not being wrapped in h5. (I think we settled on this in the newsgroup.) Note: CSS not in place yet, but I may have time to work on that today.

On Tue, 24 Feb 2015, cmhughes wrote:

Hi Rob and Dave, I think this is ready for another review; both LaTeX and html can now support any combination of the following objects side-by-side:

  • figures with captions
  • images without captions
  • blocks of text (using the paragraphs element)
  • uncaptioned tabular environments
  • tables with captions

If you run the sample-article.xml through both translation scripts, you should see a complete demonstration, including cross references in both LaTeX and html.

I believe that I have incorporated all of the feedback you've provided (and thank you again); I look forward to other feedback.

When you approve of the code, I'll re-jig the commits (not sure how to do that yet). Best Chris

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

rbeezer commented 9 years ago

No target for figures was my fault. #58 will fix it.

Figures are not knowls, since full knowlification has taken a backseat to getting XML spec mre fully-formed so authors can write with confidence. It'll get switched on once I get back to that project.

Yes, an example with a single naked

as one of the "text figures" would be good.

cmhughes commented 9 years ago

Thanks, both, for the follow-ups; I hope to get all of these issues tackled over the weekend.

I'm currently wrestling with vertical alignment in the LaTeX version.

On Thu, Feb 26, 2015 at 4:49 PM, Rob Beezer notifications@github.com wrote:

No target for figures was my fault. #58 https://github.com/rbeezer/mathbook/pull/58 will fix it.

Figures are not knowls, since full knowlification has taken a backseat to getting XML spec mre fully-formed so authors can write with confidence. It'll get switched on once I get back to that project.

Yes, an example with a single naked

as one of the "text figures" would be good.

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/pull/52#issuecomment-76214890.

cmhughes commented 9 years ago

I've addressed these issues in the latest commits:

code: There's a block of "CMH RETURN TO FIX" (or so), which I can't tell if it has been addressed or not (or should be deleted).

This is very much related to Dave's comment:

This may be someone else's problem, but paragraphs are being converted in html to "figure" not "article, and the title is not being wrapped in h5. (I think we settled on this in the newsgroup.) Note: CSS not in place yet, but I may have time to work on that today.

The CSS isn't in place yet, so I put paragraphs into a figure--the fix this note is there to remind me to return to it once the CSS has been written.

HTML output: Last one before 21.5 and then all of 21.5 and 21.6. The objects all seem to be squished tight to the left?

I don't see this with 21.5; possibly with 21.1?

HTML output: In 21.8, the valign, etc seem to be bleeding through to the captions.

Do you mean that you want the images vertically aligned separately from their captions? That'll be quite a big change, but I'm happy to try it. I'll almost certainly need more CSS elements.

When you have tables next to each other, I think the global caption should be called a "Figure" because the global object is not a table: it is a collection of tables. I am suggesting that the global caption of a sidebyside is always called a "Figure".

Ok--does that mean that references to the subtables remain Table XX.YY or are they now Figure XX.YY? See what you think about the updates.

In some of the examples it would be good to have a "p" not "paragraphs" in the sidebyside, and it would be good to put a "title" on some of the paragraphs. (When I put a p by itself, the valign attribute got lost.)

Done.

In Section 21.4 you say that the default valign is bottom, but currently that is not true. There are different defaults in different situations and for different types of objects. I'd like to understand what is the best way to handle that.

Not sure what you mean here--can you clarify? It seems like they are all defaulted to bottom...

This may be someone else's problem, but paragraphs are being converted in html to "figure" not "article, and the title is not being wrapped in h5. (I think we settled on this in the newsgroup.) Note: CSS not in place yet, but I may have time to work on that today.

Done--sidebyside/paragraphs can receive a title which is translated into h5 in html and \paragraph in LaTeX.

As always, let me know what you think. I'll happily tidy up the commits by rebasing when we think it's ready.

cmhughes commented 9 years ago

Caption alignment in LaTeX is now much better.

rbeezer commented 9 years ago

Dear Chris,

Silently smiling to myself as I worked through this. Very nice, a tour-de-force. The LaTeX preamble is a bit more technical than I'd like to have, but it all seems necessary. An author can always forego the side-by-side feature if it is critical to restyle somehow. Thanks for the general improvements to tables and figures, plus the new utilities in the "common" XSL.

I've read through your recent replies, I think the "bleeding valign" I mentioned was caption text that just got jumbled up. Ignore that comment.

Very close, thanks for your patience with this one.

A) Rebased commit was much easier for me. Thanks. But I think you reversed d840d492, which improved inline code snippets in LaTeX (present tip of dev). Maybe that is all and maybe a clever use of diff and a squash can reverse it. Or maybe you can duplicate the commit in question (cherry-pick) and squish it back into your work? Once ready, if you can "edit" a big commit into two, with XSL in the first and then sample article changes in the second I think that would be helpful. See the last technique in the stuff I sent you a while ago.

B) Some observed inconsistencies below - maybe CSS related?

C) I think I'm good with the big stuff. I'd like to have David's blessing on the HTML/CSS before merging.

Rob

  1. Section 21.2: "for example, see the subfigures in Figure 21.1. You can, of course, reference the subfigures individually, for example: Figure 21.0a." The 21.0a is not printing correctly from LaTeX, should be 21.1a? References seem correct, just how latex is ggenerating the number is nor right? Looks like maybe a consistent off-by-one? Section 21.7 has reference to Table 21.10a, which I believe shoiuld be 21.11a. (And 21.15 pointing to 21.16.) Seems fine in HTML.
  2. HTML/LaTeX: 21.1(a) or 21.1a? Do we prefer one? Can it be consistent?
  3. Can a percent width be given as a decimal? I looked at the code some, but not carefully. If I did three tables at 33.3% with halign left, then center and then right, would the two on the ends be tight to the margins? (Or is this look attainable some other way?)
  4. 21.6 "Horizontal Alignment" vertical alignment of third column of text is different HTML vs LaTeX. Third column of 21.10 seems similarly different.
  5. 21.7 "Tables Side-by-Side" (and following) "tabular body" looks centered in latex, left in HTML? Hard to tell if this is part of not really having tables yet.
  6. I like the global captions consistently as "Figure" as David suggested and you have now.
  7. Figure 21.1 is pushed left in HTML, spread in LaTeX.
cmhughes commented 9 years ago

Hi Rob, Thanks for the follow-up, I'll get working on those ASAP; I appreciate you taking the time to review it.

Rebased commit was much easier for me. Thanks. But I think you reversed d840d49, which improved inline code snippets in LaTeX (present tip of dev).

This was my first practical use of rebase, twas fun :) If I run git log from my feature/sidebyside branch, I see:

commit 091d8af17a6010e79515653f6c46849e3f7326b7
Author: cmhughes <christopher.michael.hughes@gmail.com>
Date:   Sun Feb 15 11:11:10 2015 +0000

    Side by side figures, subfigures, tables, subtables, images and paragraphs in LaTeX and html

commit d840d4923c5a5a28372ba8f5bbbddf95b370edbf
Author: Rob Beezer <beezer@ups.edu>
Date:   Thu Feb 26 21:15:18 2015 -0800

    Improve code snippets in LaTeX output

commit f16f178cd40aad8e31e7fa0fce950dfb6b39c1c8
Author: Rob Beezer <beezer@ups.edu>
Date:   Thu Feb 26 19:06:08 2015 -0800

    Cross-reference to a figure in sample article
   ...
   ...

Similarly, if I reference the Network diagram (https://github.com/rbeezer/mathbook/network) it seems that this branch is at the tip of origin/dev.... Have I misunderstood this?

Best Chris

rbeezer commented 9 years ago

Dear Chris,

checkout dev and search mathbook-latex.xsl on "lstinline"

then checkout sidebyside and search again.

Your branch is in the right place, but new commit contains changes that totally reverse the commit sitting at dev.

I'm going to guess you squashed and then rebased on dev? Just guessing, I'm no git expert.

Better perhaps to rebase your branch with a long run of commits onto dev, fix conflicts commit-by-commit as the replay happens (more localized). Then squash (fixup) all the commits down to one. Then you can edit to split out topically, or split out little incidental fixes that are unrelated (git add -p).

rebase -i is the way to go - rewrite history before the world sees it. ;-)

Rob

On 03/01/2015 11:59 AM, cmhughes wrote:

Hi Rob, Thanks for the follow-up, I'll get working on those ASAP; I appreciate you taking the time to review it.

Rebased commit was much easier for me. Thanks. But I think you reversed
d840d49
<https://github.com/rbeezer/mathbook/commit/d840d4923c5a5a28372ba8f5bbbddf95b370edbf>,
which improved inline code snippets in LaTeX (present tip of dev).

This was my first practical use of |rebase|, twas fun :) If I run |git log| from my |feature/sidebyside| branch, I see:

|commit 091d8af17a6010e79515653f6c46849e3f7326b7 Author: cmhughes christopher.michael.hughes@gmail.com Date: Sun Feb 15 11:11:10 2015 +0000

 Side by side figures, subfigures, tables, subtables, images and paragraphs in LaTeX and html

commit d840d4923c5a5a28372ba8f5bbbddf95b370edbf Author: Rob Beezer beezer@ups.edu Date: Thu Feb 26 21:15:18 2015 -0800

 Improve code snippets in LaTeX output

commit f16f178cd40aad8e31e7fa0fce950dfb6b39c1c8 Author: Rob Beezer beezer@ups.edu Date: Thu Feb 26 19:06:08 2015 -0800

 Cross-reference to a figure in sample article
...
...

Similarly, if I reference the Network diagram (https://github.com/rbeezer/mathbook/network) it seems that this branch is at the tip of |origin/dev|.... Have I misunderstood this?

Best Chris

— Reply to this email directly or view it on GitHub https://github.com/rbeezer/mathbook/pull/52#issuecomment-76627108.