openmathdocs / precalc

Modelling-based approach to pre-calculus materials: exponential, logarithmic, polynomial, rational, piecewise-defined, and trigonometric functions; transformations and composition of functions; parametric curves. Emphasizing the rule of four: graphically, numerically, verbally, and algebraically
0 stars 1 forks source link

Image production #4

Closed Alex-Jordan closed 9 years ago

Alex-Jordan commented 9 years ago

I know there is another image thread, but it seems like I may be seeding a different approach here.

How does this outline sound for image production?

I like that this would allow us to work with raw tikz commands, because I can't see how we will achieve the rich variety of graphics by restricting ourselves to something more primitive at the xml level that gets translated into tex. What do you think?

cmhughes commented 9 years ago

This sounds like a good and managable work flow.

    Put raw tikzpicture code (mostly controlled by global tikz settings of course)

    Pre-process these blocks with a new xsl sheet into standalone tex files

Yes, I think this could work--we could have the xsl insert a common preamble of tikz libraries or tikz settings into these standalone files. The only other alternative that I can think of (which I'm not entirely sure about) is to create the standalone images separately, and then link to their source in the xml; the xsl would then choose which one to use (.tex of .svg)

    pdflatex these tex files. And perhaps do something else with them like make svg images. I think there is an htlatex command/configuration that will do this. (And svg may not be the way to go here, maybe something more canvas-like can be done) 

We might also explore using the convert command from imagemagik to make an svg--I've been experimenting with this myself over the past few months, and have had some success. We can easily create batch files for both Linux/MAC and Windows to help with the conversion; arara could also help with this.

    In the xml2tex.xsl, have these blocks just use the already-created image.pdf file. This will save tons of processing time in the long run, if we don't re-process all that tikz code so often

This would certainly save time--my only concern is that already-created pdf files do not inherit font size or font style appropriately; as a result, they always seem to look and feel like external graphics.

    In the xmlthtml.xsl, have these blocks use the svg images.

Yes, this would definitely be my preference for the html.

I like that this would allow us to work with raw tikz commands, because I can't see how we will achieve the rich variety of graphics by restricting ourselves to something more primitive at the xml level that gets translated into tex. What do you think?

I certainly agree--I think that taking on the task of creating a library of translating all of the tikz commands/libraries/syntax into canvas based commands is too much at this stage.

I look forward to getting this going! Hopefully we will soon get to the stage where the foundations are sufficiently laid, and we can move on to simple content generation.

cmhughes commented 9 years ago

I'm having some issues converting to svg efficiently. Do you have a good production technique?

Alex-Jordan commented 9 years ago

I've had success using mk4ht. Specifically,

mk4ht mzlatex foo.tex "html,mathplayer";

has worked for me. I have not tested it out on anything beyond simple Cartesian graphs. I don't know if those options are ideal; they are just what I was using. Give it a try with where you are at and let me know if it shows promise.

On Fri, Dec 12, 2014 at 2:23 PM, cmhughes notifications@github.com wrote:

I'm having some issues converting to svg efficiently. Do you have a good production technique?

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/4#issuecomment-66844815.

Alex Jordan Mathematics Instructor Portland Community College

cmhughes commented 9 years ago

Sadly I have not had success with either mk4ht and htlatex.

However, I still agree that .svg should be our first choice for the .html version, and your production technique to output tikz code to standalone files outlined above should be the way to go.

I've found that http://tex.stackexchange.com/questions/51757/how-can-i-use-tikz-to-make-standalone-svg-graphics to be useful, although the first answer doesn't work reliably for me. I've found that I can produce svg files reliably using the Linux-based tool pdf2svg, and also using dvisvgm.

I think we'll need to iron out the kinks of the svg production, but otherwise we can keep moving forward.

cmhughes commented 9 years ago

I've put a first implementation of this idea (I hope it is an accurate interpration :) ) in https://github.com/openmathdocs/precalc/commit/c0ec96c69799bed9bb518ab1079c3d9b0e240882

You'll see that functions.xml contains:

        <figure xml:id="fun-fig-readgraph">
                  <code>
                    \begin{tikzpicture}
                        \begin{axis}
                        \addplot{x};
                        \end{axis}
                    \end{tikzpicture}
                  </code>
                  <description>This node contains the figure description; it will be used both in the alt tag attribute of the svg image, and in a knowl in the caption. </description>
                  <caption>caption text goes here</caption>
                </figure>

which is written to a file in chapters/./figures/function-*.*.tex, where *.* means <chapter number>.<figure number>. These .tex files need to be converted to .svg separately as their own process.

See what you think :).... lots more to do, but all of it is good :)

cmhughes commented 9 years ago

We're now using the process outlined in Rob's origin/dev which relies on the MBX script for converting tikz standalone files into svg using, for example, ./script/mbx -vv -c tikz -f svg -d ~/Documents/projects/openmathdocs/mathbook/examples/images examples/sample-article.xml

Closing this issue.