[metapost] Trying to figure out MPLib
taco at elvenkind.com
Sun Aug 5 14:51:59 CEST 2012
Yesterday, I wrote:
> PS I've just spend most of today writing a function called
> mp_solve_path() and the stuff around it. It seems to work OK, but I
> now need to write documentation and I have done enough for today. ;)
And here it is. I've tried to do the minimal amount of work on my side
for now, which means there is some work needed to get the attached
source to run.
First, and most importantly, the archive has a patch file for mp.w
in metapost 1.212 that needs to be applied before building libmplib.a.
If you have the 'patch' program, then
<top>/metapost-1.212$ patch -p0 < ~/mppath-demo/mp.w.patch
should do the trick. Otherwise, you'll have to apply the fixes by hand.
There is nothing interesting in the patch, it just removes some 'static'
classifiers from a few needed functions.
Then build libmplib.a, and copy libmplib.a, mplib.h, mpmp.h, and
mplibps.h to the mppath-demo folder.
From there, 'make' builds the simple test application 'test'.
Other files in the archive:
-- a simple makefile
-- corrects libmplib.a linkage, as posted earlier
-- header for the functions in mppath.c, including documentation
-- internals, containing quite a bit of black magic you should
not look at too closely
-- the demo app
The sources test.c and mppath.h together should make clear how it all
works, but just in case, here are some pitfalls and remarks:
* current MPlib does not like values >= abs(4096.0).
* tensions should no be less than abs(0.75)
* mp_knot lists have to be circular, so if you forget to close the
path with either mp_final_knotpair or mp_cycle_knotpair, the solve
function will fail.
* the mp_set_knot*_* functions should be called only after two knots
are already connected via mp_final_knotpair or mp_cycle_knotpair,
otherwise the internal connections become messy.
This is the main reason for mp_append_knot(), which is just a chain
of mp_creat_knot, mp_set_knot, mp_final_knotpair.
* mp_solve_path changes the path in-situ. Right now, this involves
some copying and black magic, but once the code moves to the core
mplib, that part becomes simpler (and therefore faster).
* struct mp_knot is currently defined in mplibps.h. This (and its
internals) will change in mplib 2, but I did not want to write
accessor functions right now, because even that API is not
* error discovery is a boolean value right now, but eventually in
mplib 2 there will be a way to query the exact error.
In principe, all the functions in mppath.h (except possibly for
mp_dump_path) will become part of the official API starting with mplib
2, but the maximum value limits may change.
OTOH, none of the implementation stuff in mppath.c will become part of
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5027 bytes
Desc: not available
More information about the metapost