developing large numbers of MP files for inclusion in source
Hans, Taco, et al, Our intermediate algebra text will require a large number of figures. I have two thoughts. 1. It's really inefficient to compile the entire context source file just to see what will happen to one figure. So, it seems that we should probably have a library of graphs for later inclusion in the main document. One would want to be able to compile all at once or individually if one were just working on one file. 2. The code for many individual figures is quite long and tends to obscure the flow of thought when included in the source. Again, if they were coming from an external document, that would be better. I am not looking to include the files one at a time after development. I know how to do that. Rather, I am looking for a way to gather all the source for figures in a file, compile all of the file, or just one figure from the file, then somehow call that source code into the main .tex doc during compile time. I am open to any suggestions on how to most efficiently develop and include figures (in Metapost, of course) in our main document. Thanks.
David Arnold wrote:
I am open to any suggestions on how to most efficiently develop and include figures (in Metapost, of course) in our main document.
Well, if you do not depend on metafun -- context interaction, then I would just create a metapost input file per chapter, and compile it with mpost off-line (it they are complicated, even pre-run mptopdf to save time during the inclusion phase). Then include the image in the document just like I would a 'normal' external figure or even table). I have a separate per-chapter directory for that to avoid clutter. It is not most high-tech solution, but I find it quite workable. So, my tree structure usually looks like this: ./book.tex ./style.tex ./chapter1.tex % those are components ./chapter2.tex ... ./chapter1/figure.mp ./chapter1/figure.1 ./chapter1/figure.2 ./chapter1/whatever.png ./chapter1/table-1.tex Cheers, Taco
Do you have one metapost file with many figures in it? Is it possible to just compile for the figurein that file that you want? Is there a command that will compile then show the result? On Dec 24, 2005, at 1:17 AM, Taco Hoekwater wrote:
David Arnold wrote:
I am open to any suggestions on how to most efficiently develop and include figures (in Metapost, of course) in our main document.
Well, if you do not depend on metafun -- context interaction, then I would just create a metapost input file per chapter, and compile it with mpost off-line (it they are complicated, even pre-run mptopdf to save time during the inclusion phase).
Then include the image in the document just like I would a 'normal' external figure or even table). I have a separate per-chapter directory for that to avoid clutter. It is not most high-tech solution, but I find it quite workable.
So, my tree structure usually looks like this:
./book.tex ./style.tex ./chapter1.tex % those are components ./chapter2.tex ... ./chapter1/figure.mp ./chapter1/figure.1 ./chapter1/figure.2 ./chapter1/whatever.png ./chapter1/table-1.tex
Cheers,
Taco _______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
David Arnold wrote:
Do you have one metapost file with many figures in it? Is it possible to just compile for the figurein that file that you want?
Usually I have all in one file. You can comment out figures you do not need, using: if false: beginfig(1) ... endfig; .. fi So I normally do that with the first ten when I am working on the eleventh. Later, I just change the 'false' to 'true'. Sometimes metaposts "input" command is handier, but I prefer not to have too many files on disk.
Is there a command that will compile then show the result?
I use ghostscript for preview (gv, actually) or xpdf if there is embedded math/nontrivial text, by running mptopdf first. Like I said before: my setup is not hightech at all. Cheers, Taco
Am 2005-12-24 um 01:18 schrieb David Arnold:
1. It's really inefficient to compile the entire context source file just to see what will happen to one figure. So, it seems that we should probably have a library of graphs for later inclusion in the main document. One would want to be able to compile all at once or individually if one were just working on one file.
2. The code for many individual figures is quite long and tends to obscure the flow of thought when included in the source. Again, if they were coming from an external document, that would be better.
Perhaps the "figure database" approach is right for you - create a PDF with one figure per page and write a descripting XML, see also http://wiki.contextgarden.net/Image_Database Grüßlis vom Hraban! --- http://www.fiee.net/texnique/ http://contextgarden.net http://www.cacert.org (I'm an assurer)
participants (3)
-
David Arnold -
Henning Hraban Ramm -
Taco Hoekwater