[metapost] Trying to figure out MPLib

Shriramana Sharma samjnaa at gmail.com
Sat Aug 4 06:46:16 CEST 2012

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.


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:

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

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?
Even an approximation? Is it then possible to do stroke-to-path within
MPLib itself?

c) If only filling (and unfilling if htap_p!=NULL) needs to be done,
pen_p can just be ignored, right?

3) Where is the stroke width stored?

4) The mp_stroked_object documentation does not talk about complex
pens. Does whatever is written for mp_fill_object also apply to

Shriramana Sharma

More information about the metapost mailing list