Closed Alex-Jordan closed 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.
I'm having some issues converting to svg efficiently. Do you have a good production technique?
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
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.
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 :)
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.
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?