MetaPost mailing list

Shriramana Sharma | 3 Aug 2012 08:37

$Picon$

Trying to figure out MPLib

Hello people.

I'm trying to figure out how to integrate MPLib into my C++
application. First I'm working out with C. Since the documentation is
*very* sparse I'm trying to feel my way around here. Any help would be
highly appreciated.

Basically I've compiled the stable MPost release 1.212 and from
various places in the source tree I've extracted the following files:

libkpathsea.a libmplib.a mplib.h mplibps.h

and put them in one directory. In the same directory I have my file
test.c and I'm compiling this using gcc -o test test.c -L . -l mplib
-l kpathsea. (Building using GCC 4.6.3 on Kubuntu Precise on an i5
64-bit system.) The compilation goes smoothly enough, but trying to
execute simple metapost commands using mp_execute fails. The same
commands produce a graphic on my regular metapost install.

Can anyone please help me with this? Do I need to load the plain file
or something? How to do that? Do I need to first input a \relax
command before starting with beginfig() and stuff? Please help.
Thanks!

--

-- 
Shriramana Sharma

Attachment (test.c): text/x-csrc, 656 bytes

--

(Continue reading)

headers

Shriramana Sharma | 3 Aug 2012 08:43

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 12:07 PM, Shriramana Sharma <samjnaa <at> gmail.com> wrote:
> but trying to
> execute simple metapost commands using mp_execute fails.

This is what ensues:

>> beginfig(1)
! Isolated expression.
<to be read again>
                   ;
<*> beginfig ( 1 ) ;
                     draw (0, 0) .. (2, 20) -- (10, 5) .. (3,10) .. cycle ; ...

>> draw(0
! Isolated expression.
<to be read again>
                   ,
<*> beginfig ( 1 ) ; draw (0,
                              0) .. (2, 20) -- (10, 5) .. (3,10) .. cycle ; ...

! Extra tokens will be flushed.
<to be read again>
                   ,
<*> beginfig ( 1 ) ; draw (0,
                              0) .. (2, 20) -- (10, 5) .. (3,10) .. cycle ; ...

>> endfig
! Isolated expression.
<to be read again>
                   ;

(Continue reading)

headers

Taco Hoekwater | 3 Aug 2012 09:47

$Gravatar$

Re: Trying to figure out MPLib

Hi,

On 08/03/2012 08:37 AM, Shriramana Sharma wrote:
>
> Can anyone please help me with this? Do I need to load the plain file
> or something? How to do that? Do I need to first input a \relax
> command before starting with beginfig() and stuff? Please help.
> Thanks!

Yes, if you want to use macros like beginfig(), you have to load
plain.mp. You could just copy plain.mp to the same directory
and change command to:

   "input plain; beginfig ( 1 ) ; dra... "

MPlib will find files in the current directory or with a full
path name automatically. If the file is not in the current
directory, you have to add a file finder function to the MP_options.

You could write your own based on the paths in your project, or you
could use kpathsea.

Attached test.c does a bare-bones version of using kpathsea; to
compile it you need to add the kpathsea include directories to
the compiler command line. I used this:

   gcc -o test test.c -I../../../source/texk -I.. -L . -l mplib -l kpathsea

but that depends on where you are building and where the header

(Continue reading)

headers

Shriramana Sharma | 3 Aug 2012 13:16

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 1:17 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
> es, if you want to use macros like beginfig(), you have to load
> plain.mp. You could just copy plain.mp to the same directory
> and change command to:
>   "input plain; beginfig ( 1 ) ; dra... "

Thanks that works now. Basically I am able to do multiple command= and
then EXECUTE commands. I have got the output "2 figures created" so
while I haven't investigated the actual contours yet (I'll be doing
that presently) I presume everything went on well.

A few comments/queries:

Isn't it possible to package mplib like any other library out there? I
mean I am thinking of Debian-style packages like: metapost (front-end
executable depends on libmplib), libmplib (which contains a shared
library and essential data files like plain.mp or such), libmplib-dev
(contains .h files).

Of course, if the library is small enough the split-up into multiple
packages would not be needed, but basically I expect a library to get
installed into /usr/lib and the header files for development into
/usr/include. The point of making mplib was to allow multiple
applications to link to it, no? So is it because of MPost's usage of
and relationship to TeX that it has to be installed as part of my TeX
install or something? (I still do not grok the TeX install tree yet.)

> You could write your own based on the paths in your project, or you
> could use kpathsea.

(Continue reading)

headers

Hans Hagen | 3 Aug 2012 14:09

$Picon$

Re: Trying to figure out MPLib

On 3-8-2012 13:16, Shriramana Sharma wrote:

> Isn't it possible to package mplib like any other library out there? I
> mean I am thinking of Debian-style packages like: metapost (front-end
> executable depends on libmplib), libmplib (which contains a shared
> library and essential data files like plain.mp or such), libmplib-dev
> (contains .h files).

Formats like plain.mp are independent of the library and already ship 
with tex distributions (makes not much sense otherwise, as they often 
depends on other resources like fonts). Furthermore the audience is 
pretty specific (mostly tex users) so spending too much time on 
alternative packaging is not high on the agenda of the dev team.

> Basically I want the program to be dissociated from TeX as I do not
> require any label typesetting (which I hope is the only reason MPost
> needs TeX or kpathsea) to be done by it. The important reason I am
> using MetaPost/MPLib is to calculating the control points needed for
> smooth strokes.

So, just take the library and package it indepently. Of course one might 
wonder what benefits metapost provides in that case. Also, mplib is not 
yet finished and all testing happens in a (mostly embedded in tex) 
environment.

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands

(Continue reading)

headers

Shriramana Sharma | 3 Aug 2012 14:39

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 5:39 PM, Hans Hagen <pragma <at> wxs.nl> wrote:
>> needs TeX or kpathsea) to be done by it. The important reason I am
>> using MetaPost/MPLib is to calculating the control points needed for
>> smooth strokes.
>
> So, just take the library and package it indepently. Of course one might
> wonder what benefits metapost provides in that case.

As I said above, basically I need the smooth curves Hobby algorithm.
MPost is one of the better known implementations out there. But if it
is difficult to integrate it outside a TeX environment (in which case
I'm not sure what the point of creating a library was -- only to save
multiple executable calls from within ConTeXT/LuaTeX?) then I guess it
might not be very suitable for my purpose.

I'm also looking into the Asymptote code right now as it is in C++
(which I understand better than CWEB). (I am aware Asymptote is
related to TeX also...)

Until then (I'm still looking at MPLib so) I wonder why mp_execute
requires me to input the length of the string myself. Basically I'm
doing mp_execute ( mp, command, strlen ( command ) ) -- so can't the
library calculate the length itself using strlen? Why put the burden
on the API user?

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

(Continue reading)

headers

mskala | 3 Aug 2012 15:09

$Picon$
$Favicon$

Re: Trying to figure out MPLib

On Fri, 3 Aug 2012, Shriramana Sharma wrote:
> As I said above, basically I need the smooth curves Hobby algorithm.
> MPost is one of the better known implementations out there. But if it

The algorithm is described reasonably well in a few pages of the MetaFont
book, and (I would hope) also in Hobby's original papers.  Why not
implement it yourself?  I suspect that might be less work than trimming
all the TeX dependencies off of MetaPost.
--

-- 
Matthew Skala
mskala <at> ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/
--
http://tug.org/metapost/

headers

Taco Hoekwater | 3 Aug 2012 15:15

$Gravatar$

Re: Trying to figure out MPLib

On 08/03/2012 03:09 PM, mskala <at> ansuz.sooke.bc.ca wrote:
> On Fri, 3 Aug 2012, Shriramana Sharma wrote:
>> As I said above, basically I need the smooth curves Hobby algorithm.
>> MPost is one of the better known implementations out there. But if it
>
> The algorithm is described reasonably well in a few pages of the MetaFont
> book, and (I would hope) also in Hobby's original papers.  Why not
> implement it yourself?  I suspect that might be less work than trimming
> all the TeX dependencies off of MetaPost.

If you are not using fonts nor using labels, there really are no
dependencies to metapost, except for that silly kpathsea thing.

--
http://tug.org/metapost/

headers

Shriramana Sharma | 3 Aug 2012 15:56

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 6:45 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
> If you are not using fonts nor using labels, there really are no
> dependencies to metapost, except for that silly kpathsea thing.

Hi -- is it possible to fix this "sneaky dependency"?  I could
clone/pull SVN or whatever if necessary.

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Taco Hoekwater | 3 Aug 2012 16:13

$Gravatar$

Re: Trying to figure out MPLib

On 08/03/2012 03:56 PM, Shriramana Sharma wrote:
> On Fri, Aug 3, 2012 at 6:45 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
>> If you are not using fonts nor using labels, there really are no
>> dependencies to metapost, except for that silly kpathsea thing.
>
> Hi -- is it possible to fix this "sneaky dependency"?  I could
> clone/pull SVN or whatever if necessary.

Since 1.212 is the stable release, meaning that I am not eager to
create a 1.213 right now, and the current development source is a bit
unreliable (as Hans wrote already), by far the easiest solution is to
use the attached C file as an extra source:

   gcc -c -o fixkpse.o fixkpse.c
   gcc -c -o test.o test.c
   gcc -o test test.o fixkpse.o -L . -l mplib

But I will make sure to fix this fake dependency for the next stable
release of metapost / mplib.

Best wishes,
Taco

Attachment (fixkpse.c): text/x-csrc, 174 bytes

--
http://tug.org/metapost/

headers

Shriramana Sharma | 3 Aug 2012 16:14

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 7:43 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
> by far the easiest solution is to
> use the attached C file as an extra source:
> ...
> But I will make sure to fix this fake dependency for the next stable
> release of metapost / mplib.

Hey thanks that is *very* nice of you! 

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Shriramana Sharma | 3 Aug 2012 16:43

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 6:45 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
>
> If you are not using fonts nor using labels, there really are no
> dependencies to metapost, except for that silly kpathsea thing.

Hi. As I said on my offlist mail, basically what I'll be using MPLib
for is to find control points for smooth curves and possible for
finding intersection/tangent points. I will be programming using Qt
(either in C++ or Python) and that has support for the fonts/labels
stuff (which I still don't need for my particular application).

So given your patch for the kpathsea problem, does this mean that I
can execute a program linked against the libmplib.a as it is produced
by compiling the tarball on a system which does not have TeX? What
will happen if a label command is included in the command argument I
pass to mp_execute and the system doesn't have the least trace of TeX
on it?

And pardon me if I missed this somewhere, but does the source-tree as
it is distributed even have a *build*-dependency on any
TeX-components? (I have seen packages which have a build-dependency on
TeX [for documentation or such] but not for execution, which is why I
ask.) As you can see, as far as possible, I would like to not have any
dependency on TeX either for building or for execution.

Also, can you please point me to where in the source tree I should go
to make a shared library out of MPost rather than the static library
which is produced right now?

Thanks a lot for all your kind help!

(Continue reading)

headers

Taco Hoekwater | 3 Aug 2012 17:42

$Gravatar$

Re: Trying to figure out MPLib

Hi,

On 08/03/2012 04:43 PM, Shriramana Sharma wrote:
>
> So given your patch for the kpathsea problem, does this mean that I
> can execute a program linked against the libmplib.a as it is produced
> by compiling the tarball on a system which does not have TeX?

Yes.

> What
> will happen if a label command is included in the command argument I
> pass to mp_execute and the system doesn't have the least trace of TeX
> on it?

For a TeX label, nothing will happen. For an actually typeset metapost
string, you will get an error in the 'terminal' and 'log' outputs
because the font and its support files will not be present. These
are not fatal errors, so perhaps it does not bother you.

> And pardon me if I missed this somewhere, but does the source-tree as
> it is distributed even have a *build*-dependency on any
> TeX-components?

It is set out not to need a pre-existing installation of any kind of
TeX/MP, but it is vaguely possible that something crept in because
my system is littered with TeX and mp installations and at times it
is amazingly hard to keep autoconf 'localized'.

(Continue reading)

headers

Shriramana Sharma | 3 Aug 2012 18:14

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 9:12 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
>> So given your patch for the kpathsea problem, does this mean that I
>> can execute a program linked against the libmplib.a as it is produced
>> by compiling the tarball on a system which does not have TeX?
>
> Yes.

Very nice.

>> What
>> will happen if a label command is included in the command argument I
>> pass to mp_execute and the system doesn't have the least trace of TeX
>> on it?
>
> For a TeX label, nothing will happen.

A TeX label? I don't know what that is. I meant the labels that we
attach to points -- I suppose this is what you mean below:

> For an actually typeset metapost
> string, you will get an error in the 'terminal' and 'log' outputs
> because the font and its support files will not be present. These
> are not fatal errors, so perhaps it does not bother you.

Yes, and especially since for my purpose I am not going to be using
labels anyway. My question was just out of curiosity.

>> And pardon me if I missed this somewhere, but does the source-tree as
>> it is distributed even have a *build*-dependency on any
>> TeX-components?

(Continue reading)

headers

Hans Hagen | 3 Aug 2012 18:21

$Picon$

Re: Trying to figure out MPLib

On 3-8-2012 18:14, Shriramana Sharma wrote:

> A TeX label? I don't know what that is. I meant the labels that we
> attach to points -- I suppose this is what you mean below:

   btex bla etex => parsed and piped to tex and piped back as mp picture

compared to

   instring => internal mp (but using a tfm file)

the tex variant is the one with proper typesetting quality

> Yes, and especially since for my purpose I am not going to be using
> labels anyway. My question was just out of curiosity.

labels can also be used for annotating bit and pieces of a shape 
(tracing and debugging)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
--
http://tug.org/metapost/

(Continue reading)

headers

Hans Hagen | 3 Aug 2012 18:06

$Picon$

Re: Trying to figure out MPLib

On 3-8-2012 16:43, Shriramana Sharma wrote:

> And pardon me if I missed this somewhere, but does the source-tree as
> it is distributed even have a *build*-dependency on any
> TeX-components? (I have seen packages which have a build-dependency on
> TeX [for documentation or such] but not for execution, which is why I
> ask.) As you can see, as far as possible, I would like to not have any
> dependency on TeX either for building or for execution.

unfortunately, the tex source tree is not the easiest to deal with (also 
related to kpse / web2c stuff as mentioned by taco already but tangle 
and weave are also factors)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
--
http://tug.org/metapost/

headers

Shriramana Sharma | 3 Aug 2012 16:27

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 6:39 PM,  <mskala <at> ansuz.sooke.bc.ca> wrote:
>
> The algorithm is described reasonably well in a few pages of the MetaFont
> book, and (I would hope) also in Hobby's original papers.  Why not
> implement it yourself?  I suspect that might be less work than trimming
> all the TeX dependencies off of MetaPost.

Hi thanks -- that's one of the approaches I'm considering. But I'm
wondering whether I have the mathematical knowledge to understand and
implement the algorithm properly. (Who knows, maybe I could surprise
myself!)

I also need to produce PS output (the other thing I'm using MP for) to
import glyphs into a font -- but probably I can use Cairo for that.

So basically if there were a simple C library which would get MP style
input for a path -- at least for the continuous curve parts of it not
including straight lines (which are not an issue and are split up
internally by MF/MP anyway) -- and write to a linked list of a struct
with node, ctrl, ctrl, node or such -- it could be used from virtually
any programming language (since most other languages provide
interfaces to C).

FWIW http://tex.stackexchange.com/questions/54771/curve-through-a-sequence-of-points-with-metapost-and-tikz
has an incomplete python implementation of the algorithm by one J L
Diaz (perhaps s/he is on this list?).

[BTW this is not directly relevant to the thread subject, but I have
to say that I completely agree with the above J L Diaz when s/he says
"The algorithm is used in METAFONT and MetaPost, but the source code

(Continue reading)

headers

Taco Hoekwater | 3 Aug 2012 17:48

$Gravatar$

Re: Trying to figure out MPLib

Hi,

On 08/03/2012 04:27 PM, Shriramana Sharma wrote:
>
> So basically if there were a simple C library which would get MP style
> input for a path -- at least for the continuous curve parts of it not
> including straight lines (which are not an issue and are split up
> internally by MF/MP anyway) -- and write to a linked list of a struct
> with node, ctrl, ctrl, node or such -- it could be used from virtually
> any programming language (since most other languages provide
> interfaces to C).

[answered off-list. Something can be done rather easily, but still takes
a bit of work. Will post the end results once complete.]

--
http://tug.org/metapost/

headers

Hans Hagen | 3 Aug 2012 18:08

$Picon$

Re: Trying to figure out MPLib

On 3-8-2012 16:27, Shriramana Sharma wrote:

> I also need to produce PS output (the other thing I'm using MP for) to
> import glyphs into a font -- but probably I can use Cairo for that.

it would be interesting if mplib could be hooked into fontfforge

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
--
http://tug.org/metapost/

headers

Shriramana Sharma | 3 Aug 2012 18:14

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 9:38 PM, Hans Hagen <pragma <at> wxs.nl> wrote:
> it would be interesting if mplib could be hooked into fontfforge

Yeah -- a similar thought occurred to me too. And since I've been
discovering to my pleasant surprise that MPLib doesn't require TeX for
building or executing pure drawing without labels, this would actually
be possible. Unfortunately, I'm not a fan of FontForge's GUI. I'm
planning on doing a simple thing using Qt for my own purposes (but
which will of course be released). So that's probably someone else's
agenda item...

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Shriramana Sharma | 4 Aug 2012 02:01

$Picon$

Re: Trying to figure out MPLib

Hello so I'm trying to access the internals of the linked list I
generated by (multiple calls to) mp_execute by doing:

	results = mp_rundata ( mp ) ;
	curfig = results -> edges ;
	while ( curfig != NULL )
	{
		printf ( "Current figure #%d has internal figure number %d, and
bounding box ll (%d,%d) to ur (%d,%d)\n", fignum, curfig -> charcode,
curfig -> minx, curfig -> miny, curfig -> maxx, curfig -> maxy ) ;
		curfig = curfig -> next ;
	}

and I get the output:

Current figure #0 has internal figure number 10, and bounding box ll
(-2063982,-1039307) to ur (690340,2603781)
Current figure #1 has internal figure number 20, and bounding box ll
(49152,-16384) to ur (1982464,671744)

I am guessing if I just do a simple integer division of this by 65536,
it'll be lossy and so I have to convert to double before I do that
right? Or would float be enough?

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

(Continue reading)

headers

Shriramana Sharma | 4 Aug 2012 06:46

$Picon$

Re: Trying to figure out MPLib

On Sat, Aug 4, 2012 at 5:31 AM, Shriramana Sharma <samjnaa <at> gmail.com> wrote:
> I am guessing if I just do a simple integer division of this by 65536,
> it'll be lossy and so I have to convert to double before I do that
> right? Or would float be enough?

Well double is not very costly nowadays so I went for it and output to
printf using %g.

Next:

The documentation of mp_fill_object says that if the pen is a one-knot
pen then the client of the library should fill path_p and draw path_p
with pen_p, but if the pen is a multi-knot one with
pen_p->next!=pen_p, then the pen's path has already been calculated so
I have to fill path_p and htap_p.

Based on this my questions regarding mp_fill_object and mp_stroked_object:

1) Do I understand correctly that:

a) If this object is produced by fill, then there is no pen.

b) If this object is produced by filldraw, then there is a pen.

c) It is not possible for an object to be filled with one colour and
drawn with another -- for that I have to fill and draw the same path
separately using different colours? (This is obviously not an mplib
question but a generic metapost one.)

2) In the case of a complex pen:

(Continue reading)

headers

Taco Hoekwater | 4 Aug 2012 10:46

$Gravatar$

Re: Trying to figure out MPLib

On 08/04/2012 06:46 AM, Shriramana Sharma wrote:
>
> Based on this my questions regarding mp_fill_object and mp_stroked_object:
>
> 1) Do I understand correctly that:
>
> a) If this object is produced by fill, then there is no pen.

Yes.

> b) If this object is produced by filldraw, then there is a pen.

Yes.

> c) It is not possible for an object to be filled with one colour and
> drawn with another -- for that I have to fill and draw the same path
> separately using different colours? (This is obviously not an mplib
> question but a generic metapost one.)

True.

> 2) In the case of a complex pen:
>
> a) I am supposed to fill path_p and *fill* htap_p or *unfill* htap_p?
> The documentation just says "fill path_p and htap_p".

Both fills, I think (as htap is reversed already), but that should be 
obvious after a quick test.

> b) the documentation says "the path has been pre-processed for you" --

(Continue reading)

headers

Shriramana Sharma | 4 Aug 2012 14:23

$Picon$

Re: Trying to figure out MPLib

On Sat, Aug 4, 2012 at 2:16 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
>> a) I am supposed to fill path_p and *fill* htap_p or *unfill* htap_p?
>> The documentation just says "fill path_p and htap_p".
>
> Both fills, I think (as htap is reversed already), but that should be
> obvious after a quick test.

With evenOddFill in Qt I think irrespective of the direction of the
path it will be unfilled. OK thanks.

>> b) the documentation says "the path has been pre-processed for you" --
>> by this do I understand that the outline of the stroke has been
>> converted into paths and represented as the path_p and reverse htap_p?
>> In which case, has the does this mean MPLib has a stroking algorithm?
>
> Yes it does, but for non-elliptical pens only.

Ouch.  Greedy me -- expecting too much! 

But could you please mention that in the documentation?

>> Even an approximation? Is it then possible to do stroke-to-path within
>> MPLib itself?
>
> Yes. In fact, you get that for free whether you want to or not.

I guess this also applies only to non-elliptical pens.

BTW you mention "non-elliptical". If I define a generic bean-shape
(for example) using smooth curves and use it as a pen, would it be

(Continue reading)

headers

Shriramana Sharma | 4 Aug 2012 16:16

$Picon$

Re: Trying to figure out MPLib

So I guess I finally worked my way through the major part of the
library (at least that which concerns me -- the fill and stroked
objects). I've attached my code. (The same with binaries included will
be temporarily available at:
https://sites.google.com/site/jamadagni/files/temp/mplib-20120804-1748.zip.)

By running my code I discovered that the stroke width for an
elliptical pen had been "ingeniously" hidden as the pen's single
node's left control point's x coord. Somewhat ad-hoc, but OK.

----

BTW maybe to this one also you guys will say "the current development
is far ahead of the documentation" but I think I should say it. Please
refer to the ptrbug.c file and its output.

The mp_knot documentation says that the "next" member of an mp_knot
struct will point to the next knot or NULL. But I found out (by
wondering why my program which was testing for "while ( curnode !=
NULL )" was running in an infinite loop) that the last node in a pen
or path has in fact been linked to the first one (or in a single node
pen it points to itself as the next). [As I said, I'm working on the
stable 1.212 release tarball.]

Curiously, this is in tune with the mp_fill_object documentation which
speaks about a complex pen having pen_p->next!=pen_p, but basically I
feel it would be advisable to make it so that the mp_knot
documentation is true. That way, when I am iterating through a linked
list, I can just stop when the pointer becomes NULL, rather than
having to store the pointer of the first knot and then test for it. (A

(Continue reading)

headers

Taco Hoekwater | 4 Aug 2012 17:01

$Gravatar$

Re: Trying to figure out MPLib


Hi,

Really quickly (and perhaps not very precise):

On 08/04/2012 04:16 PM, Shriramana Sharma wrote:
> The mp_knot documentation says that the "next" member of an mp_knot
> struct will point to the next knot or NULL. But I found out (by

The doc is wrong (as you discovered). last knot points to first knot,
and that is because the code dealing with the metapost --cycle
construct needs to update/access some data in the first node from
within the last node.

> I wonder what you guys are doing in your PS/SVG backends to test for
> the completion of the list. Are you also storing the first pointer and
> testing it?

Yes.

> (Unfortunately CWEB is in fact difficult for me to read as
> I have remarked.) Wouldn't it be easier to make it so that the last
> item's next pointer is indeed NULL?

For some usage cases yes, but it would uglify other cases.

> Next, looking at the output of my program (which is now able to output
> all nodes and control points generated by MPLib) I noticed that
> straight lines are also allotted control points 1/3rd and 2/3rd the
> way between the two endpoints. But I have also seen that the PS output

(Continue reading)

headers

Taco Hoekwater | 5 Aug 2012 14:51

$Gravatar$

Re: Trying to figure out MPLib

Hi all,

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:

(Continue reading)

headers

Shriramana Sharma | 9 Aug 2012 14:36

$Picon$

Re: Trying to figure out MPLib

Hello Taco and thanks for your work on this -- this is really great! I
am replying in some delay because I wanted to review the code
carefully [and yes I did look at some of the black magic too! ].

On Sun, Aug 5, 2012 at 6:21 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
>         <top>/metapost-1.212$ patch -p0 < ~/mppath-demo/mp.w.patch
> 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'.

Done. I used the following shorter Makefile:

OBJECTS = test.o fixkpse.o mppath.o
all: $(OBJECTS) mppath.h libmplib.a
	gcc -Wall -g -o test $(OBJECTS) -L . -l mplib  -lm
.c.o:
	gcc -Wall -g -c $<

>   mppath-demo/mppath.h
>         -- header for the functions in mppath.c, including documentation
>   mppath-demo/mppath.c
>         -- internals, containing quite a bit of black magic you should
>         not look at too closely

One small suggestion for change:

mppath.h: extern int mp_cycle_knotpair (MP mp, mp_knot *p, mp_knot *q);
mppath.c: int mp_cycle_knotpair (MP mp, mp_knot *p, mp_knot *q)

mppath.h: extern int mp_final_knotpair (MP mp, mp_knot *p, mp_knot *q);

(Continue reading)

headers

Taco Hoekwater | 9 Aug 2012 16:07

$Gravatar$

Re: Trying to figure out MPLib


Hi,

On 08/09/2012 02:36 PM, Shriramana Sharma wrote:
> One small suggestion for change:
>
> mppath.h: extern int mp_cycle_knotpair (MP mp, mp_knot *p, mp_knot *q);
> mppath.c: int mp_cycle_knotpair (MP mp, mp_knot *p, mp_knot *q)
>
> mppath.h: extern int mp_final_knotpair (MP mp, mp_knot *p, mp_knot *q);
> mppath.c: int mp_final_knotpair (MP mp, mp_knot *q, mp_knot *first)
>
> Could you please change the labeling as following:
>
> mp_close_path (MP mp, mp_knot *p, mp_knot *first ) ;
> mp_close_path_cycle (MP mp, mp_knot *p, mp_knot *first ) ;

I've done that locally, but I will not post the code again.

> Actually in your code it's mp_cycle_knotpair and not final_knotpair.

True and in fact final_knotpair would not work, but that is just
ugly internals that are likely to change anyway.

> I think the only reason you need the cycle/final_knotpair here is to
> set the next pointer, left/right_type (to open) and tension (to 1). In
> which case, would it not be better to have another internal function
> "link_to" or something? Then you can substitute the mp_cycle_knotpair
> within append by that, and use cycle_knotpair (aka close_path_cycle)
> only to actually close the path. Of course, cycle_knotpair aka

(Continue reading)

headers

Shriramana Sharma | 9 Aug 2012 16:21

$Picon$

Re: Trying to figure out MPLib

On Thu, Aug 9, 2012 at 7:37 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
> int mp_close_path_cycle (MP mp, mp_knot *p, mp_knot *q)

Can you please change q to first? Likewise for close_path. Thanks.

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Shriramana Sharma | 12 Aug 2012 12:57

$Picon$

Re: Trying to figure out MPLib

Hello Taco -- I tried running your mppath demo using my recently
devised sharedlib libmplib.so and am having some problems -- hope you
can help. (I checked and the sharedlib was built from the same
[patched] sources as the staticlib which works.)

The execution halts at mppath.c line 254:

    mp_make_choices(mp, PATH_LOC(cur_exp));

I am not able to figure out beyond that. I even stepi-ed into the
program using gdb (something which I am totally inexperienced at) but
all I was able to get was:

(gdb) stepi
0x0000000000401c12      253         mp->arith_error=0;
(gdb) stepi
254         mp_make_choices(mp, PATH_LOC(cur_exp));
(gdb) stepi
0x0000000000401c20      254         mp_make_choices(mp, PATH_LOC(cur_exp));
(gdb) stepi
0x0000000000401c27      254         mp_make_choices(mp, PATH_LOC(cur_exp));
(gdb) stepi
0x0000000000401c2b      254         mp_make_choices(mp, PATH_LOC(cur_exp));
(gdb) stepi
0x0000000000401c32      254         mp_make_choices(mp, PATH_LOC(cur_exp));
(gdb) stepi
0x0000000000401c35      254         mp_make_choices(mp, PATH_LOC(cur_exp));
(gdb) stepi
0x0000000000401c38      254         mp_make_choices(mp, PATH_LOC(cur_exp));
(gdb) stepi

(Continue reading)

headers

luigi scarso | 5 Aug 2012 15:23

$Picon$

Re: Trying to figure out MPLib

On Sat, Aug 4, 2012 at 5:01 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:

Hi,

Really quickly (and perhaps not very precise):

On 08/04/2012 04:16 PM, Shriramana Sharma wrote:

....But I wonder:

psout.w (ll 5070..) records that it is make_choices that produces
these and make_path and make_envelope instead make the controls
identical to the nodes themselves. IMHO the latter is a much better
approach as it does not make one bother with detecting whether the
curvature is slight or not and simple == tests are enough. Also,
someone may actually use a curve of very slight curvature for whatever
reason. So can the behaviour of make_choices please be aligned with
that of make_path/make_envelope in the matter of straight lines?

Probably, but I have to investigate that.

control_points == nodes implies that one cannot calculate the derivatives

with the simple formula of derivative, but must introduce another check.

Also very slight curvature are always a problem, w.r.t the choice of

control_points == nodes or not are not so important.

luigi

--
http://tug.org/metapost/

headers

Shriramana Sharma | 6 Aug 2012 16:39

$Picon$

Re: Trying to figure out MPLib

On Sun, Aug 5, 2012 at 6:53 PM, luigi scarso <luigi.scarso <at> gmail.com> wrote:
> control_points == nodes implies that one cannot calculate the derivatives
> with the  simple formula of derivative, but must introduce another check.

Are you referring to the usage of "direction of" etc?

But anyhow in the case of the nodes created by make-path and
make-envelope that will be a problem no? Or are those paths not
subjectable to direction operators?

IMHO it would be cleaner to introduce that check there instead of
here. The direction of operators are not used so often that
introducing the check there would be a severe performance penalty or
anything. (Even then, how much processing time are a few
addition/subtraction operations and if statements going to take) OTOH
the output functions are used very often. While I'm not saying that
there is a big performance issue *there*, I am saying that in the
interests of ease of usage of the library (and not just in the psout
and svgout backends) it would be better to do this i.e. assign control
points to nodes for straight lines.

The make-choices function has the direct first hand knowledge of which
segments are straight because it is processing the "--" input. So it
can assign the controls to the nodes without testing for anything
else. OTOH testing for a minimal curvature in the output functions
might not be such a good idea especially if we are going to go for
higher precision in the future -- what is the maximum curvature which
would be considered as straight and would it be good for the code (aka
coders) to arbitrarily determine that? Equating the controls to the
nodes would eliminate the problem because binary equal is always
binary equal!

IMHO clearly tagging straight segments as straight which are straight
*by user specification* is better than doing it to those which are
straight by *assumption* of the program.

> Also very slight curvature are always a problem, w.r.t the choice of
> control_points == nodes or not are not so important.

Um, am not sure what exactly you mean. Can you restate that?

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Taco Hoekwater | 6 Aug 2012 17:42

$Gravatar$

Re: Trying to figure out MPLib

On 08/06/2012 04:39 PM, Shriramana Sharma wrote:
>
> IMHO clearly tagging straight segments as straight which are straight
> *by user specification* is better than doing it to those which are
> straight by *assumption* of the program.

I agree, but because straight lines are expressed as two explicit
curl statements ('--' is a macro expanding to '{curl1}..{curl1}'),
finding the right spot in solve_choices() to intercept this case
(as opposed to other {curl} values) is not immediately obvious to
me from the code.

Best wishes,
Taco
--
http://tug.org/metapost/

headers

Shriramana Sharma | 8 Aug 2012 08:36

$Picon$

Re: Trying to figure out MPLib

On Mon, Aug 6, 2012 at 9:12 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
> I agree, but because straight lines are expressed as two explicit
> curl statements ('--' is a macro expanding to '{curl1}..{curl1}'),
> finding the right spot in solve_choices() to intercept this case
> (as opposed to other {curl} values) is not immediately obvious to
> me from the code.

Um, isn't it possible to like check for node->curlvalue == 1 &&
node->next->curlvalue == 1?

BTW where are the curl, tension and direction values stored before
everything is converted to explicit control points? Are the control
point variables being ad-hoc overloaded for this as well?

Thanks.

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Taco Hoekwater | 8 Aug 2012 09:46

$Gravatar$

Re: Trying to figure out MPLib


On Aug 8, 2012, at 8:36 AM, Shriramana Sharma wrote:

> On Mon, Aug 6, 2012 at 9:12 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
>> I agree, but because straight lines are expressed as two explicit
>> curl statements ('--' is a macro expanding to '{curl1}..{curl1}'),
>> finding the right spot in solve_choices() to intercept this case
>> (as opposed to other {curl} values) is not immediately obvious to
>> me from the code.
> 
> Um, isn't it possible to like check for node->curlvalue == 1 &&
> node->next->curlvalue == 1?
> 
> BTW where are the curl, tension and direction values stored before
> everything is converted to explicit control points? Are the control
> point variables being ad-hoc overloaded for this as well?

Yes.

Best wishes,
Taco
--
http://tug.org/metapost/

headers

Shriramana Sharma | 4 Aug 2012 17:07

$Picon$

Re: Trying to figure out MPLib

On Sat, Aug 4, 2012 at 5:53 PM, Shriramana Sharma <samjnaa <at> gmail.com> wrote:
>
> BTW you mention "non-elliptical". If I define a generic bean-shape
> (for example) using smooth curves and use it as a pen, would it be
> stroked? Or are any pens with smooth curves a no-no and only linear
> pens are stroked?

Another oops on my part: only now do I read the MP doc that makepen
will convert paths to be polygonal. Sorry.

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Hans Hagen | 5 Aug 2012 11:25

$Picon$

Re: Trying to figure out MPLib

On 4-8-2012 17:07, Shriramana Sharma wrote:
> On Sat, Aug 4, 2012 at 5:53 PM, Shriramana Sharma <samjnaa <at> gmail.com> wrote:
>>
>> BTW you mention "non-elliptical". If I define a generic bean-shape
>> (for example) using smooth curves and use it as a pen, would it be
>> stroked? Or are any pens with smooth curves a no-no and only linear
>> pens are stroked?
>
> Another oops on my part: only now do I read the MP doc that makepen
> will convert paths to be polygonal. Sorry.

concerning pens ... mp relies on a combination of path and postscript 
drawing properties to get paths with non circular pens (in pdf this is 
somewhat different as there we need to output the path twice for that to 
happen) .. this is why taco pointed to the pdf conversion code

concerning dealing with the result of mp: if I were you I'd not too much 
depend on those internals as (just as with luatex) things will change 
when it suits the dev purpose

probably the best place to look is the mp-lua interface as that one uses 
an abstract (and stable) view of the result (i.e. access to all the 
properties of the image after it's constructed)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
--
http://tug.org/metapost/

headers

Shriramana Sharma | 5 Aug 2012 13:00

$Picon$

Re: Trying to figure out MPLib

Hello thanks for this response.

On Sun, Aug 5, 2012 at 2:55 PM, Hans Hagen <pragma <at> wxs.nl> wrote:
> concerning dealing with the result of mp: if I were you I'd not too much
> depend on those internals as (just as with luatex) things will change when
> it suits the dev purpose

Which internals? Do you mean the API of MPLib?

> probably the best place to look is the mp-lua interface as that one uses an
> abstract (and stable) view of the result (i.e. access to all the properties
> of the image after it's constructed)

I do not know (or plan on knowing) Lua. C/C++/Python all play with
each other very nicely and have many well-developed and open source
libraries for various purposes including GUI app development (which is
what I am eventually targeting). Lua is less well known than Python
and does not have as many interfacing tools with C/C++ as Python does.
For example right now I'm reading up on the Cython documentation to
see if I can make a Python interface to MPLib. ]

[IMHO it's unfortunate that the whitespace-semantics of Python make it
difficult to integrate it with TeX (IIUC). Else Python would be the
logical IMHO simply because it is most widely used. I realize that may
not be the best criterion so I'll stop here...]

So basically I am OK with tracking the API changes. Since the basic
logic is the same, I presume any changes you would make would not be
too radical.

IMHO it would also be good to have an external (i.e. outside
LuaTeX/ConTeXT) check on the MPLib changes as well...  A consistent
API without too many radical changes would also be what is needed for
what you said about FontForge possibly using MPLib to come to
fruition.

Thanks for all your feedback and help!

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Taco Hoekwater | 4 Aug 2012 10:39

$Gravatar$

Re: Trying to figure out MPLib

On 08/04/2012 02:01 AM, Shriramana Sharma wrote:
>
> I am guessing if I just do a simple integer division of this by 65536,
> it'll be lossy and so I have to convert to double before I do that
> right? Or would float be enough?

There is not a lot of penalty for double these days, so I would suggest
to use that. And yes, numbers in metapost are typically stored in a
32bit int as 14.16 bits. Better typecast first, divide later, otherwise
you loose the fractional part.

Best wishes,
Taco

--
http://tug.org/metapost/

headers

Shriramana Sharma | 4 Aug 2012 18:52

$Picon$

Re: Trying to figure out MPLib

Just for the record:

On Fri, Aug 3, 2012 at 7:57 PM, Shriramana Sharma <samjnaa <at> gmail.com> wrote:
> So basically if there were a simple C library which would get MP style
> input for a path -- at least for the continuous curve parts of it not
> including straight lines (which are not an issue and are split up
> internally by MF/MP anyway) --

I realized there's a logical fallacy to my above statement. Not only
the continuous parts, but also the straight lines need to be evaluated
as part of the path, because the curves (barring {dir} or explicit
control specifications) will try to be as smoothly connecting to the
straight lines as possible. So it is necessary to know the straight
line segments also to determine the appropriate smoothening control
points for the curved segments.

> and write to a linked list of a struct
> with node, ctrl, ctrl, node or such -- it could be used from virtually
> any programming language (since most other languages provide
> interfaces to C).

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Taco Hoekwater | 3 Aug 2012 15:14

$Gravatar$

Re: Trying to figure out MPLib

Hi,

On 08/03/2012 02:39 PM, Shriramana Sharma wrote:
>
> Until then (I'm still looking at MPLib so) I wonder why mp_execute
> requires me to input the length of the string myself. Basically I'm
> doing mp_execute ( mp, command, strlen ( command ) ) -- so can't the
> library calculate the length itself using strlen? Why put the burden
> on the API user?

For embedded zeroes, of course. I honestly thought that would be
obvious.

Coming back to a remark you made earlier: the silly dependency to
libkpathsea is an error that happens because by including config.h,
which includes kpathsea/config.h, mp.w accidentally includes
kpathsea/debug.h indirectly. That last one redefines fopen() and
fclose() unless -DNO_DEBUG is passed along. Alternatively, you
could define kpse_fopen_trace() and kpse_fclose_trace() funcitons
in your own C source, then the linker will find those instead.

Sorry about this, but I never expected kpathsea to be that sneaky.

Best wishes,
Taco

--
http://tug.org/metapost/

headers

Shriramana Sharma | 3 Aug 2012 15:58

$Picon$

Re: Trying to figure out MPLib

On Fri, Aug 3, 2012 at 6:44 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
> For embedded zeroes, of course. I honestly thought that would be
> obvious.

Sorry it wasn't. And sorry if I am still not able to comprehend: Why
would embedded zeroes -- and by that I assume you mean not the digit 0
but the nullcharacter \0 -- be part of command input to mp_execute? I
thought the user is supposed to input the exact same commands as they
would input in an .mp file. I still don't comprehend how a nullchar \0
would be part of MP syntax.

--

-- 
Shriramana Sharma
--
http://tug.org/metapost/

headers

Taco Hoekwater | 3 Aug 2012 16:17

$Gravatar$

Re: Trying to figure out MPLib

On 08/03/2012 03:58 PM, Shriramana Sharma wrote:
> On Fri, Aug 3, 2012 at 6:44 PM, Taco Hoekwater <taco <at> elvenkind.com> wrote:
>> For embedded zeroes, of course. I honestly thought that would be
>> obvious.
>
> Sorry it wasn't. And sorry if I am still not able to comprehend: Why
> would embedded zeroes -- and by that I assume you mean not the digit 0
> but the nullcharacter \0 -- be part of command input to mp_execute? I
> thought the user is supposed to input the exact same commands as they
> would input in an .mp file. I still don't comprehend how a nullchar \0
> would be part of MP syntax.

Well, that may not be 'normal' or 'useful', but it is definitely legal
input.

Best wishes,
Taco

--
http://tug.org/metapost/

headers

Hans Hagen | 3 Aug 2012 17:55

$Picon$

Re: Trying to figure out MPLib

On 3-8-2012 14:39, Shriramana Sharma wrote:
> On Fri, Aug 3, 2012 at 5:39 PM, Hans Hagen <pragma <at> wxs.nl> wrote:
>>> needs TeX or kpathsea) to be done by it. The important reason I am
>>> using MetaPost/MPLib is to calculating the control points needed for
>>> smooth strokes.
>>
>> So, just take the library and package it indepently. Of course one might
>> wonder what benefits metapost provides in that case.
>
> As I said above, basically I need the smooth curves Hobby algorithm.
> MPost is one of the better known implementations out there. But if it
> is difficult to integrate it outside a TeX environment (in which case
> I'm not sure what the point of creating a library was -- only to save
> multiple executable calls from within ConTeXT/LuaTeX?) then I guess it
> might not be very suitable for my purpose.

indeed that was the main objective ... integration in tex ... of course 
other usage is possible but has a low priority given that the next major 
objective is support for decimal calculations and that project is not 
yet finished .. it's all a matter of time

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
--
http://tug.org/metapost/

headers

Boguslaw Jackowski | 6 Aug 2012 13:24

$Picon$

Re: Trying to figure out MPLib


Hi,

Shriramana Sharma:
> As I said above, basically I need the smooth curves Hobby algorithm.
> MPost is one of the better known implementations out there. But if it

Matthew Skala:
> The algorithm is described reasonably well in a few pages of the MetaFont
> book, and (I would hope) also in Hobby's original papers.  Why not
> implement it yourself?  I suspect that might be less work than trimming
> all the TeX dependencies off of MetaPost.

Bull's eye! -- "is described reasonably well". :)

I spent a few months trying to understand in details how it works,
assembling scattered pieces of the description (The MFbook,
J.D. Hobby's Thesis and the relevant publications, most
notably J.R. Manning's "Continuity conditions for spline
curves", and last but not least -- the MF.web source).

I prepared a careful note for myself -- alas, in mother tongue,
i.e., in Polish. :-/ I'm going to translate it into English,
but the time is always too short. There is a chance, however, that by
the end of this year I'll manage to be ready with the translation.
Thanks for providing the motivation.

Nevertheless, Marek Ry\'cko (who is a mathematician but knows
rather little about the intestines of MF/MP) was able within
a much shorter time spread than I spent on translating the
documentation to "MF-less math" was able to implement the
algorithm in Python. If somebody is interested in the code --
please contact Marek.

Cheers -- Jacko

--

-- 
BOP s. c.
ul. Bora-Komorowskiego 24, 80-377 Gdansk, Poland
tel. (+48 58) 553 46 59,  fax (+48 58) 511 03 81
bop <at> bop.com.pl, http://www.bop.com.pl
--
http://tug.org/metapost/

headers

luigi scarso | 6 Aug 2012 14:26

$Picon$

Re: Trying to figure out MPLib

On Mon, Aug 6, 2012 at 1:24 PM, Boguslaw Jackowski <jacko <at> bop.com.pl> wrote:

Hi,

Shriramana Sharma:

As I said above, basically I need the smooth curves Hobby algorithm.
MPost is one of the better known implementations out there. But if it

Matthew Skala:

The algorithm is described reasonably well in a few pages of the MetaFont
book, and (I would hope) also in Hobby's original papers. Why not
implement it yourself? I suspect that might be less work than trimming
all the TeX dependencies off of MetaPost.

Bull's eye! -- "is described reasonably well". :)

I spent a few months trying to understand in details how it works,
assembling scattered pieces of the description (The MFbook,
J.D. Hobby's Thesis and the relevant publications, most
notably J.R. Manning's "Continuity conditions for spline
curves", and last but not least -- the MF.web source).

I prepared a careful note for myself -- alas, in mother tongue,
i.e., in Polish. :-/ I'm going to translate it into English,
but the time is always too short. There is a chance, however, that by
the end of this year I'll manage to be ready with the translation.
Thanks for providing the motivation.

+1 for me (of course I should say)

--
luigi

--
http://tug.org/metapost/