luaTeX and on-the-fly MetaPost compilation
Hi, I didn't have the opportunity to touch luaTeX yet, but let me ask one question in advance: Since luaTeX has a built-in MetaPost interpreter, is it possible to refer to a certain figure in a MetaPost source file for inclusion, instead of a compiled figure? As an example, I would like to say in a TeX document (syntax may differ) \includeMetaPost{foo.2} and this should not refer to the pre-compiled file foo.2 but to section figure(2); ... endfig; in file foo.mp and compile it on-the-fly. Would that be possible? Rationale: I do not want to mix TeX and MetaPost code. Probably, I'll stick with compiling .mp files prior to the TeX run anyway, but I'm curious about this option. Best regards, Stephan Hennig
Stephan Hennig wrote:
Hi,
I didn't have the opportunity to touch luaTeX yet, but let me ask one question in advance: Since luaTeX has a built-in MetaPost interpreter, is it possible to refer to a certain figure in a MetaPost source file for inclusion, instead of a compiled figure?
As an example, I would like to say in a TeX document (syntax may differ)
\includeMetaPost{foo.2}
In principle something like that is possible, but it needs an extension to the current system, because you have to filter out the specific figure you really want, and I don't think Hans has code for that already (but I could be wrong). Best wishes, Taco
Stephan Hennig wrote:
Hi,
I didn't have the opportunity to touch luaTeX yet, but let me ask one question in advance: Since luaTeX has a built-in MetaPost interpreter, is it possible to refer to a certain figure in a MetaPost source file for inclusion, instead of a compiled figure?
As an example, I would like to say in a TeX document (syntax may differ)
\includeMetaPost{foo.2}
and this should not refer to the pre-compiled file
foo.2
but to section
figure(2); ... endfig;
in file
foo.mp
and compile it on-the-fly. Would that be possible?
mplib is still just mp so it ptocessed what is passed to it; no intelligence is added to the mp kernel however, when using the lib ons is in control over what is passed to it in the past i did what you describe in metafun by using just a macro (loadfigure) which filters the image from a file; in luatex we can be more clever (i admit that i hadn;t yet thought of replacing the macro -) using lua we get something ... function filterfromMPblob(data,number) return (data:match(string.format("beginfig%%(%s%%).-endfig",number)) or "") .. " ;" end test this with: str = [[ beginfig(1) draw fullcircle ; endfig ; beginfig(2) draw fullcircle ; endfig ; ]] print(filterfromMPblob(str,2)) glue to tex: \def\includeMetaPost#1#2% io.loaddata is part of l-io.lua {\directlua0{tex.print(filterfromMPblob(io.loaddata("#1",#2)))}} of course this need to be embeded in some general mp support (i'll add it to my todolist; actually a bit more is involved since one probably wants to include the data between the figures too since it may be called upon) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen schrieb:
glue to tex:
\def\includeMetaPost#1#2% io.loaddata is part of l-io.lua {\directlua0{tex.print(filterfromMPblob(io.loaddata("#1",#2)))}}
of course this need to be embeded in some general mp support
(i'll add it to my todolist; actually a bit more is involved since one probably wants to include the data between the figures too since it may be called upon)
Thank you for the outline. For the exact mechanism of how to process an .mp file I think there are three possible cases: 1. Strictly process what's between figure(n)..endfig only. For this example pair pnt; pnt:=origin; beginfig(1); pnt:=(100,100); drawdot pnt; endfig; beginfig(2); drawdot pnt; endfig; end compilation of figure 2 should fail, since variable pnt is undeclared. 2. Process everything up-to the specified figure, omitting stuff inside non-matching figure numbers. In the example above, the output of figure 2 should be a dot at point (0,0). This case is convenient if multiple figures share common variables or macros that are defined outside the scope of beginfig..endfig. This should be the default case for .mp file interpretation. 3. Process everything up-to the specified figure, including all non-matching figures, but discard their output. That is, in the example, the output of figure 2 should be a dot at point (100,100), since pnt was modified in figure 1. Note, this is not a pressing feature for me. The advantage is that MetaPost and TeX code can be held in separate files (which has several advantages) and users can easily compile the code in a single TeX run, without knowing about Makefiles. Well, there is the \write18 feature. But that is as difficult to use as a Makefile or even more difficult for the inexperienced user. Best regards, Stephan Hennig
Stephan Hennig wrote:
Thank you for the outline. For the exact mechanism of how to process an .mp file I think there are three possible cases:
1. Strictly process what's between figure(n)..endfig only.
2. Process everything up-to the specified figure, omitting stuff inside non-matching figure numbers.
3. Process everything up-to the specified figure, including all non-matching figures, but discard their output.
4. Start a new MP instance, process the whole file, save and remember the outputs (store fig.1, fig.2, fig.3 etc), then immediately close the MP instance again. The advantage is that this makes the metapost input behave exactly the same as a true external figure, something that is not possible when an already running MP instance is re-used. This is important, because the state of an already running instance can be altered in such a way that a perfectly valid metapost source suddenly fails to run. That may happen with embedded metapost code as well of course, but in that case it is much easier to correct and diagnose the problem. Best wishes, Taco
Stephan Hennig wrote:
Note, this is not a pressing feature for me. The advantage is that MetaPost and TeX code can be held in separate files (which has several advantages) and users can easily compile the code in a single TeX run, without knowing about Makefiles. Well, there is the \write18 feature. But that is as difficult to use as a Makefile or even more difficult for the inexperienced user.
i'll put it on my todo list (let me know if it gets pressing -) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Hans Hagen -
Stephan Hennig -
Taco Hoekwater