Feature/tikz preamble - Githubissues

Alex-Jordan commented 9 years ago

This allows us to put extra packages and other preamble content into the code that goes into a <tikz> tag. Without this, everything you would put into a <tikz> tag goes into the body of a standalone tex document, and the preamble of that tex document is only what is hard coded into extract-tikz.xsl.

There is an example in sample-article.xml using the forest package.

I think this is good, but a side effect of the changes that I made is that no tags within a <tikz> tag are recognized (except the new <tikz-extra-preamble>). My understanding is that formerly, only text (tex code) content would have been inside a <tikz> tag, so this should be backward compatible.

I'll create a pull request to origin as well.

cmhughes commented 9 years ago

In the context of our figures, will we have to add the same extra preamble to every one of our figures?

I can see that for Rob's case, he'll probably want the per-figure approach, but will this work for our OMD? For our vast quantity of figures, it seems like a modification of xsl/extract-tikz.xsl would be appropriate....

Alex-Jordan commented 9 years ago

We can hard code more into our version of extract-tikz.xsl if we want to. But there are certainly things we wouldn't care to have in every standalone preamble. For instance, in working on an applications section of scla (Second Course in Linear Algebra), I wanted to use the forest package. There'd be no need to load that package globally. You can imagine the same for a mindmap image, etc.

Alex-Jordan commented 9 years ago

And of course you are totally right that we will want to hard code all our pgfplots settings and things like that into extract-tikz.xsl for consistency.

An alternative would be to copy extract-tikz.xsl into either an omd-specific version or a precalc-specific version. Then use the mbx script with the copy.

Alex-Jordan commented 9 years ago

I should have tested on the tex side too. That side doesn't behave as I though tit did. See my comment at https://github.com/rbeezer/mathbook/pull/49.

cmhughes commented 9 years ago

Thanks for the follow-ups; I'll hold off testing this until I hear back from you on either this pull or the one to origin.

On Sunday, February 8, 2015, Alex Jordan notifications@github.com wrote:

I should have tested on the tex side too. That side doesn't behave as I though tit did. See my comment at rbeezer#49 https://github.com/rbeezer/mathbook/pull/49.

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/mathbook/pull/10#issuecomment-73391447.

cmhughes commented 9 years ago

I've been thinking about our workflow... When we have a feature that we're submitting to origin/dev, do we need to submit another pull request to OMD? I don't mind either, but I just wonder about it...

cmhughes commented 9 years ago

Looks like this is close to being accepted upstream--what do you think about closing this here?

Alex-Jordan commented 9 years ago

So I squashed some commits together and that turned out to cause problems when Rob tried to pull for testing. We're working on fixing that issue. But yes, once it is pulled with Rob, I don't foresee any reason why we would have it different for OMD. So might as well just pull from Rob's dev.

Alex-Jordan commented 9 years ago

Rob pulled https://github.com/rbeezer/mathbook/pull/55 into origin/dev. I could make a parallel pull request here in omd's dev. But is that any better than we just pull origin/dev into our dev?

I still have the quantity feature to fine tune. And you are working on side by side objects, if not also more table features. However we pull in latex-image-code, we should watch out for any conflicts with our open feature branches. If I knew more what I was talking about, I might suggest rebasing our feature branches from origin/dev. But I'm not really sure that even makes sense. Thoughts?

cmhughes commented 9 years ago

I say we close this pull request, and use your second choice: pull from origin/dev.

As I understand it, each of our feature branches tracks origin/dev; as such running git pull should update them. Once updated, we should be able to run git push to omd, and it's updated. Would there be any need to rebase?

I've used the workflow I've described above on sidebyside and it works fine....

On Sunday, February 22, 2015, Alex Jordan notifications@github.com wrote:

Rob pulled rbeezer#55 https://github.com/rbeezer/mathbook/pull/55 into origin/dev. I could make a parallel pull request here in omd's dev. But is that any better than we just pull origin/dev into our dev?

I still have the quantity feature to fine tune. And you are working on side by side objects, if not also more table features. However we pull in latex-image-code, we should watch out for any conflicts with our open feature branches. If I knew more what I was talking about, I might suggest rebasing our feature branches from origin/dev. But I'm not really sure that even makes sense. Thoughts?

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/mathbook/pull/10#issuecomment-75423706.

cmhughes commented 9 years ago

I should also have said that I don't really understand under what circumstances we could/should rebase....

On Sunday, February 22, 2015, Chris Hughes < christopher.michael.hughes@gmail.com> wrote:

I say we close this pull request, and use your second choice: pull from origin/dev.

As I understand it, each of our feature branches tracks origin/dev; as such running git pull should update them. Once updated, we should be able to run git push to omd, and it's updated. Would there be any need to rebase?

I've used the workflow I've described above on sidebyside and it works fine....

On Sunday, February 22, 2015, Alex Jordan <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Rob pulled rbeezer#55 https://github.com/rbeezer/mathbook/pull/55 into origin/dev. I could make a parallel pull request here in omd's dev. But is that any better than we just pull origin/dev into our dev?

I still have the quantity feature to fine tune. And you are working on side by side objects, if not also more table features. However we pull in latex-image-code, we should watch out for any conflicts with our open feature branches. If I knew more what I was talking about, I might suggest rebasing our feature branches from origin/dev. But I'm not really sure that even makes sense. Thoughts?

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/mathbook/pull/10#issuecomment-75423706.

Alex-Jordan commented 9 years ago

I don't understand rebasing, but I have a suspicion that it could help in the following circumstances:

Suppose origin/dev is at commit A. I branch for a new feature, committing away. So do you. Meanwhile, Rob is doing other things and origin/dev moves on to commit B, commit C, etc. All before we have had a chance to submit pull requests for our features. I'm loosely gathering from things Rob has said that if we rebase our features to commit C, it could help.

For clarity, this pull request is already closed. This one and #49 at MBX were based on my branch called feature/tikzPreamble. The commits were many, and jumbled, and Rob requested cleaning the commits to be smaller in number and more organized by what had been accomplished. I couldn't find the cool git way to do that, so I made new branch from origin/dev called feature/latex-image. Then I used git diff to compare it to feature/tikzPreamble, and just copied the appropriate changes. It went in at origin/dev as pull request #55.

In summary, feature/tikzPreamble should be killed (I'll try to do that to the GitHub branch later). And feature/latex-image is what went into origin/dev.

openmathdocs / mathbook

Feature/tikz preamble #10