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 :)
I think my branch is ok now... Here's what I did, mainly for my own reference:
git rebase -i HEAD~4
# fixup commits, re-ordered commit
git log
vim xsl/mathbook-latex.xsl # to check the differences
git rebase -i HEAD~2
git log # checked order of commits
vim xsl/mathbook-latex.xsl # check lstinline was still in place
git status
# check commit differences with origin/dev
git rebase origin/dev
# fixes differences
git status
# now only 1 commit behind
git push omd feature/sideBySideObjects
# failed because I was re-writing history
git push --force omd feature/sideBySideObjects
# succeeded, because only Jedi's can re-write history
That looks like the correct procedure to me, I'll check result here in a bit.
David F - you should be just fine if you picked this up earlier, the change is
not related to sidebyside.
Rob
On 03/01/2015 01:19 PM, cmhughes wrote:
I think my branch is ok now... Here's what I did, mainly for my own reference:
| git rebase -i HEAD~4
fixup commits, re-ordered commit
git log
vim xsl/mathbook-latex.xsl # to check the differences
git rebase -i HEAD~2
git log # checked order of commits
vim xsl/mathbook-latex.xsl # check lstinline was still in place
git status
# check commit differences with origin/dev
git rebase origin/dev
# fixes differences
git status
# now only 1 commit behind
git push omd feature/sideBySideObjects
# failed because I was re-writing history
git push --force omd feature/sideBySideObjects
# succeeded, because only Jedi's can re-write history
I've rebased off the latest tip of origin/dev, and split into two commits: one for the xsl, and one for sample-article.xml.
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.
Fixed.
HTML/LaTeX: 21.1(a) or 21.1a? Do we prefer one? Can it be consistent?
Both now have 21.1(a); I'm happy to change to 21.1a if you'd prefer.
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?)
The width can now be a decimal value; you'll see a demonstration in the sample-article.xml. I believe that your idea would work, although it's pretty tricky to test with tables being in so much flux at the moment :)
21.6 "Horizontal Alignment" vertical alignment of third column of text is different HTML vs LaTeX. Third column of 21.10 seems similarly different.
I think this is a CSS thing. @davidfarmer please can you confirm? From my perpesctive, it appears that I'm feeding the correct arguments, but perhaps I'm mistaken....
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.
They are now centered by default.
Figure 21.1 is pushed left in HTML, spread in LaTeX.
Not sure what to do about this; it seems that the html needs a 'filling' div container...? How would you want the CSS to be handled?
21.1(a) is just fine, I only cared that they would be the same, though I do
prefer the () version, if it is technically just as easy. I know on the HTML
side, customizing list labels is next-to-impossible.
I know David has this on his list, so I'm going to wait on his HTML feedback and
then I'll do another (final?) pass.
Thanks,
Rob
On 03/04/2015 02:15 PM, cmhughes wrote:
I've rebased off the latest tip of |origin/dev|, and split into two commits: one
for the |xsl|, and one for |sample-article.xml|.
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.
Fixed.
HTML/LaTeX: 21.1(a) or 21.1a? Do we prefer one? Can it be consistent?
Both now have |21.1(a)|; I'm happy to change to |21.1a| if you'd prefer.
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?)
The width can now be a decimal value; you'll see a demonstration in the
|sample-article.xml|. I believe that your idea would work, although it's pretty
tricky to test with |table|s being in so much flux at the moment :)
21.6 "Horizontal Alignment" vertical alignment of third column of text is
different HTML vs LaTeX. Third column of 21.10 seems similarly different.
I think this is a |CSS| thing. @davidfarmer https://github.com/davidfarmer
please can you confirm? From my perpesctive, it /appears/ that I'm feeding the
correct arguments, but perhaps I'm mistaken....
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.
They are now centered by default.
Figure 21.1 is pushed left in HTML, spread in LaTeX.
Not sure what to do about this; it seems that the |html| needs a 'filling' div
container...? How would you want the CSS to be handled?
I am looking into the html markup and also checking that the LaTeX and HTML output look similar.
1) Is the "paragraphs" conversion new to this branch, or is it provided elsewhere?
I think the html markup of paragraphs should look like this (modelling off a theorem):
(white space added for clarity)
< article class="sidebyside" >
< h5 class="heading" > the title < /h5 >
< p > the remainder is a series of p paragraphs < /p >
< /article >
2) The LaTeX has everything centered and equally spaced. That is appropriate in many case,
but usually not when there is text on the left and non-text on the right (especially when
the non-text item lacks a caption). I propose that text on the left side be set flush with
the left edge of the main text, except when the adjacent block is also text (here "text"
meand "paragraphs" or "p".) Thoughts?
3) The LaTeX output is not something that could easily be converted back to MBX.
Are we okay with that? The alternative would be a macro that took a bunch of arguments,
and all the centering and caption/minipage gymnastics would be in the macro definition.
As a slightly different question, I am wondering about the need to output all the captioning
commands when there is no caption.
Right now the main thing holding me back is proper html markup for "paragraphs" so
I can work on the CSS.
Would it be reasonable to have a "paragraphs" in a sidebyside convert to an article in html,
while a "paragraphs" in a chapter/section/subsection/etc converts to a section? In both
cases it would have class="paragraphs".
I also noticed that html sections from MBX have a header, but SL2X omits the header.
Since the header from MBX only contains an h1, I don't see the reason to have the header.
It is easy with XSL to handle "general" paragraphs one way, with overrides for
sidebyside/paragraphs. Only the latter could have a caption, so we need to deal
with it differently anyway. By "reasonable" I presume you meant do-able
technically.
Related: once this is ready, I'll need to replace "paragraph" by "paragraphs",
make deprecation warnings, etc. I just upgraded deprecation warnings in
anticipation of this and of the changes for tables.
On 03/05/2015 11:07 AM, davidfarmer wrote:
Would it be reasonable to have a "paragraphs" in a sidebyside convert to an
article in html,
while a "paragraphs" in a chapter/section/subsection/etc converts to a section?
In both
cases it would have class="paragraphs".
I also noticed that html sections from MBX have a header, but SL2X omits the header.
Since the header from MBX only contains an h1, I don't see the reason to have
the header.
1) Is the "paragraphs" conversion new to this branch, or is it provided elsewhere?
I think the html markup of paragraphs should look like this (modelling off a theorem):
(white space added for clarity)
< article class="sidebyside" >
< h5 class="heading" > the title < /h5 >
< p > the remainder is a series of p paragraphs < /p >
< /article >
This is now implemented, although the current CSS doesn't seem to contain the necessary bits to support it.
2) The LaTeX has everything centered and equally spaced. That is appropriate in many case,
but usually not when there is text on the left and non-text on the right (especially when
the non-text item lacks a caption). I propose that text on the left side be set flush with
the left edge of the main text, except when the adjacent block is also text (here "text"
meand "paragraphs" or "p".) Thoughts?
Provided that the width element is specified appropriately by the user so that the total width is 100% this will work fine. It sounds like you'd like sidebyside to create something similar to the display of the wrapfig environment.
But in order for that to apply, there has to be a space between
each item in the .sidebyside (so each item is treated as a
separate "word").
I tried to do that by having an :after with content:' ' after
each item in the sidebyside. But that space does not occur
where I want it. Not in Safari, anyway. Not sure if I am doing
it wrong, or if things are not implemented correctly.
One solution is to create the html with a space between each element
of a sidebyside. Normally we don't like that, but since it is unlikely
that we actually want two items directly adjacent, maybe it is okay
this time?
Not sure if that might cause a problem when the widths add up to
exactly 100 percent.
On Sat, 7 Mar 2015, cmhughes wrote:
I don't think the paragraphs are being given their width styling.
Should be fine now.
Also, I couldn't tell if there was an example of a bare "p" in a sidebyside.
Yes, see lines 1876--1877 of the sample article.
—
Reply to this email directly or view it on GitHub.[AAM6LNW2blw5e-X4hRX9P3fXQwYKiDUAks5ny3MSgaJpZM4Dgq8J.gif]
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.
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.
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.
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:
<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
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
</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
far enough.
—
Reply to this email directly or view it on GitHub.[AAM6LKL-iGzo6SRXG-oKmK8U_i1AhHsyks5n10xggaJpZM4Dgq8J.gif]
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.
@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.
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.
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
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.
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?
Split off the "sidebyside" template from "figure" to be its own template.
Do any setup, wrapup here in this template (eg seems like something happens after the last sub-item with your stack?).
In between have <xsl:apply-templates select="." mode="sidebyside" />
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.
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.
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.
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.
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.)
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.)
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.
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!
cmhughes
commented
9 years ago 
rbeezer
commented
9 years ago 
davidfarmer
commented
9 years ago 
Alex-Jordan
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.xmlwith bothmathbook-html.xslandmathbook-latex.xslyou'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.)
LaTeXI'd mainly like to know if this looks ok to you; I've loaded a couple of packages on the
LaTeXside, both from the same author as the excellentcaptionpackage (loaded in one of my other pull requests). Thehtmlside usesdivboxes.I'll happily receive all feedback, and look forward to adding more to this once I've heard back :)
Best Chris