[metapost] Trying to figure out MPLib

Taco Hoekwater taco at elvenkind.com
Sat Aug 4 17:01:09 CEST 2012


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?


> (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
> uses lineto and does not indiscriminately use curveto for everything.

As you discovered, it reverse-engineers those 1/3-2/3 items into linetos

> ....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.

> The MPLib doc says that knots can original either from the user or the
> program. Can you clarify what kind of knots are generated by the
> program?

The points created by circular pen->path conversion, but also and much
more importantly, there are temporary intermediate knots inserted
during the pen envelope calculation to aid in switching the edges of
the rectangular pen. These are removed later when they are no longer
needed, but for that they need to be recognisable to the program.

Best wishes,

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. ;)

More information about the metapost mailing list