[metapost] Trying to figure out MPLib

[Shriramana Sharma]

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
minor inconvenience, but a meaningless one IMO unless you can clarify
why the behaviour is so.)

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? This is true for the other linked
lists in the library, the mp_edge_object-s and the mp_graphic_objects.
Only the pens and paths are weird. Why?

---

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.

I had myself realized that it would not be possible to determine
whether this segment is straight or not directly from the control
points without giving some allowance for error and indeed psout.w (ll
5082..) does this to output lineto instead of curveto. 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?

---

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? I thought it only determined the control points? Or is this
needed for custom pens or something?

Thanks all especially Taco and Hans for your patience with my queries!

-- 
Shriramana Sharma
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplib-src-20120804-1748.zip
Type: application/zip
Size: 12039 bytes
Desc: not available
URL: <http://tug.org/pipermail/metapost/attachments/20120804/bb0f4218/attachment-0001.zip>