Taco Hoekwater | 12 Mar 16:52 2015

Fwd: problem with mpost number of strings exceeded

Begin forwarded message:

Date: 12 Mar 2015 16:49:43 CET
From: Denis Roegel <denis.roegel <at> loria.fr>
To: Taco Hoekwater <taco <at> elvenkind.com>
Subject: problem with mpost number of strings exceeded

Hi Taco,

I am running into a problem with a metapost file which generates about 20 files,
each being about 500kb. These files use a lot of labels (with latexmp) and eventually
I get metapost capacity exceeded [number of strings = 31228]
(on an old distribution). I have tried to increase max_strings to 200000, pool_size to
more than a million, main_memory has been set to 3000000, (I changed texmf.cnf
and regenerated the format with fmtutil), but I still get that error.
What should I increase? In the worst case, I could split my file to generate a smaller
number of figures.



Franck Pastor | 9 Mar 17:01 2015

Bug with the binary operator `point ... on ...` from Metafun

I’ve just encountered a very puzzling bug with the binary operator `point <len> of <path>` defined in the
Metafun format.

In the Metafun manual (http://www.pragma-ade.com/general/manuals/metafun-p.pdf), p. 61, this
binary operator is defined as such:

primarydef len of pat =
  (arctime len of pat) of pat

So if I write `point 0 on pat`, it should return the starting point of the path <pat>, right? But n. To the
contrary, it returns the end point of <pat>! Stranger yet, if I try `point (arctime 0 of pat) of pat`, it
returns the starting point, as expected. 

This weird behavior is illustrated by the following program, to be run with the Metafun format of course:

path line[]; line1 = origin -- 3cm*right; line2 = line1 yshifted -1cm;
draw line1; draw line2;
pickup pencircle scaled 3bp;
draw point 0 of line1; % draw a dot at the start point, as expected
draw point 0 on line1; % draws a dot at the end point!!!!!
draw point (arctime 0 of line2) of line2; % draws a dot at the starting point…

An idea about what is wrong? 

I use MetaPost 1.902 and Metafun version 1.004, from TeX Live 2014.

Thanks in advance,

Franck Pastor

luigi scarso | 21 Jan 09:14 2015

Turning Number and QuickSort

It seems that the University College Cork has some problem to deliver emails to the metapost list,
so I forward some notes that 
Marc van Dongen has sent to me last days:

I have noticed lots of problems with standard metapost, including
lots of problems related to rounding and an error in turningnumber.

I re-implemented turningnumber (in mpost) and it seems to work for
my purpose. The implementation is quite simple and it avoids rounding
errors. (It's still possible to reduce more rounding but I don't
think it's needed.) Please let me know if you want the implementation.
(I still have to do some proper testing on it.)
The files are in attachment.

% This is a simple implementation to determine whether a  path
% is drawn anti clockwise. To do this, it computes the signed
% area of the path consisting of the support points of the path.
% ASSUMPTION: _pat_ does have a non-zero area.
vardef IsAntiClockwise( expr pat ) =
    ((cycle pat) and (Area( pat ) > AREA_ACCURACY))
    %(turningnumber( pat ) > 0)

vardef Area( expr pat ) =
    save a, len, sum; numeric a[], len[], sum;
    len := length pat;
    % First we compute (twice) the signed areas of the triangles
    % _(0,0) -- (point i of pat) -- (point (i + 1) of pat) -- cycle_
    for i = len - 1 downto 0:
        a[ i ] := Det( point i of pat, point (i + 1) of pat );
    % Since adding the sizes may result in large rounding errors,
    % we sort them in descending order
    SortAbsGeq( a )( len );
    % The remaining statements compute the sum of the signed areas
    % in a ``robust'' fashion, trying to minimise rounding. A little
    % bit more robust would be to first compute the frequencies of
    % the entries in _a_, then multiplying each unique number in
    % _a_ by its frequency, then sorting the products, and finally
    % adding the products.
    % e.g. [1,2,1,1];
    % sort it -> [2,1,1,1];
    % compute frequencies -> [2:1,1:3];
    % compute products -> [2,3];
    % sort -> [2,3];
    % add -> 5.
    sum := 0;
    for i = len - 1 downto 0:
        sum := sum + a[ i ];
    % We could have just returned _sum_ but
    % this way we get the actual signed area.

vardef QuickSort( suffix a, cmp )( expr size ) =
    QuickSort_( a, cmp )( 0, size - 1 );

vardef QuickSort_( suffix a, cmp )( expr lo, hi ) =
    if lo < hi:
        save sep; numeric sep;
        %Swop( a )( lo, floor( (lo + hi) / 2 ) );
        Swop( a )( lo, lo + floor( uniformdeviate( hi - lo - 1 ) ) );
        sep := Partition( a, cmp, lo, hi );
        Swop( a )( lo, sep );
        QuickSort_( a, cmp )( lo, sep - 1 );
        QuickSort_( a, cmp )( sep + 1, hi );

vardef Partition( suffix a, cmp )( expr lo, hi ) =
    save dest, pivot; numeric dest, pivot;

    dest := lo;
    pivot := a[ lo ];
    for i = lo + 1 upto hi:
        if cmp( a[ i ], pivot ):
            dest := dest + 1;
            Swop( a )( dest, i );

vardef Swop( suffix a )( expr fst, snd ) =
    save tmp; numeric tmp;
    tmp := a[ fst ];
    a[ fst ] := a[ snd ];
    a[ snd ] := tmp;

vardef SortAbsGeq( suffix a )( expr size ) =
    save CMP__;
    vardef CMP__( expr fst, snd ) =
        (abs( fst ) >= abs( snd ))
    QuickSort( a, CMP__ )( size );

dongen | 5 Jan 11:55 2015

Problem Installing MPost Development Version


A few days ago I downloaded the most recent development
version of metapost. When I tried to install it I got the
following error:

gcc: error:
/home/dongen/LaTeX/MetPost/metapost-1.999/build/libs/gmp/gmp-build/.libs/libgmp.a: No such
file or directory
make: *** [mpost] Error 1
strip: 'build/texk/web2c/mpost': No such file
ls: cannot access build/texk/web2c/mpost: No such file or directory

FWIW I do have libgmp installed but (obviously) it's not
in /home/dongen/LaTeX/MetPost/metapost-1.999/build/libs/gmp/.

Any suggestions?

Thanks in advance for your help.


Marc van Dongen

Wojciech A. Koszek | 3 Dec 10:17 2014

With prologues=3 and SVG output, METAPOST dies with SIGSEGV


I wanted to document my solution to a problem from the ``Cracking the coding
interview'' on measuring angles between clock's pointers. I have 1 figure
for this for now, and METAPOST crashes when I try to compile my image.

I figured it works fine with prologues=1 or 2 for both MPS and SVG output.

For prologues=3 it works fine with MPS, but gets a SIGSEGV with SVG as an


Will finish OK:

	wget -O bug_2.mp http://pastebin.com/5irnjVHB
	mpost bug_2.mp

No go and make g_use_svg = 1. It will fails with ``Segmentation fault''.


	wkoszek|1:08:06|0|/home/wkoszek/o/mp$ mpost --version

	MetaPost 1.208
	Copyright 2009 AT&T Bell Laboratories.
	There is NO warranty.  Redistribution of this software is
	covered by the terms of both the MetaPost copyright and
	the Lesser GNU Lesser General Public License.
	For more information about these matters, see the files
	named COPYING, COPYING.LESSER and the MetaPost source.
	Primary author of MetaPost: John Hobby.
	Current maintainer of MetaPost: Taco Hoekwater.


Wojciech A. Koszek
wkoszek <at> FreeBSD.czest.pl

Wojciech A. Koszek | 3 Dec 10:16 2014

Command "show" on a non-empty "path" makes mpost(1) return with error code 1


This is what I expected: ``show'' called with any valid argument should be
fine to put and shouldn't be modifying mpost(1) exit behavior. In
particular: return code should always be 0.

What I see: ``show'', when placed in a figure's script, is changing a
return code of the ``mpost'', if the thing I try to show is a path, and it's
not empty. This destroys my Makefile-based flow.


	wget -O sample.mp http://pastebin.com/YNkg4E05

	path	circle;
	%circle = (0,0);
	%circle = fullcircle;
	show circle;

If you call as is:

	$ mpost sample.mp > /dev/null
	$ echo $?

If you uncomment line 3:

	$ mpost sample.mp > /dev/null
	$ echo $?

I think it's a bug.


Wojciech A. Koszek
wkoszek <at> FreeBSD.czest.pl

William Adams | 21 Nov 20:29 2014

Use metaflow.mp in lualatex using mplib?

Metflow is a package which allows one to do flow charts in metapost:


When I try to use it, I get the error:

! Incomplete string token has been flushed.

How do I fix this?



William Adams
senior graphic designer
Fry Communications
Sphinx of black quartz, judge my vow.


Graham Douglas | 5 Nov 13:27 2014

Re: MPlib: some observations on the mp_gr_copy_object(MP mp, mp_graphic_object*p) function

On 05/11/2014 11:00, metapost-request <at> tug.org wrote:
> Send metapost mailing list submissions to
> 	metapost <at> tug.org
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://tug.org/mailman/listinfo/metapost
> or, via email, send a message with subject or body 'help' to
> 	metapost-request <at> tug.org
> You can reach the person managing the list at
> 	metapost-owner <at> tug.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of metapost digest..."
> Today's Topics:
>    1. MPlib: some observations on the mp_gr_copy_object(MP mp,
>       mp_graphic_object*p) function (Graham Douglas)
>    2. Re: MPlib: some observations on the mp_gr_copy_object(MP mp,
>       mp_graphic_object*p) function (luigi scarso)
> ----------------------------------------------------------------------
> Message: 1
> Date: Mon, 3 Nov 2014 22:33:20 +0000
> From: Graham Douglas <graham.douglas <at> readytext.co.uk>
> To: <metapost <at> tug.org>
> Subject: [metapost] MPlib: some observations on the
> 	mp_gr_copy_object(MP mp, mp_graphic_object*p) function
> Message-ID: <545802B0.5060200 <at> readytext.co.uk>
> Content-Type: text/plain; charset="ISO-8859-1"

Hi All

Just to update/close this post, I made a note of this as a tracker item
at http://tracker.luatex.org/
should it be considered worth looking into.

Best wishes

Graham Douglas | 3 Nov 23:33 2014

MPlib: some observations on the mp_gr_copy_object(MP mp, mp_graphic_object*p) function

Hi All

I'm working with MPlib (version 1.801, compiled under Windows 7, 64 bit
) and using mp_gr_copy_object(MP mp,mp_graphic_object*p) to create a way
to cache graphics produced by MPlib (which is now working well, after
the "fixes" below.).  I noticed that the mp_gr_copy_object(MP
mp,mp_graphic_object*p) function (in psout.c) was not copying a number
of key values into the new object --- such as ljoin, lcap colour
information etc. My apologies if this has been fixed or, of course,
there are good reasons that these values are not copied (or it is some
other error on my part). Anyway, I thought I'd make a note of this just
in case. I have highlighted the changes I made within psout.c

Warm wishes

mp_graphic_object* mp_gr_copy_object(MP mp,mp_graphic_object*p)


case mp_fill_code:
tf= (mp_fill_object*)mp_new_graphic_object(mp,mp_fill_code);
gr_pre_script(tf)= mp_xstrdup(mp,gr_pre_script((mp_fill_object*)p));
gr_post_script(tf)= mp_xstrdup(mp,gr_post_script((mp_fill_object*)p));
gr_path_p(tf)= mp_gr_copy_path(mp,gr_path_p((mp_fill_object*)p));
gr_htap_p(tf)= mp_gr_copy_path(mp,gr_htap_p(p));
gr_pen_p(tf)= mp_gr_copy_path(mp,gr_pen_p((mp_fill_object*)p));

//GMD Graham fixes --------------------------------->
tf->ljoin = ((mp_fill_object*)p)->ljoin;
tf->miterlim = ((mp_fill_object*)p)->miterlim;
tf->color_model = ((mp_fill_object*)p)->color_model;
tf->color.a_val = ((mp_fill_object*)p)->color.a_val;
tf->color.b_val = ((mp_fill_object*)p)->color.b_val;
tf->color.c_val = ((mp_fill_object*)p)->color.c_val;
tf->color.d_val = ((mp_fill_object*)p)->color.d_val;
q= (mp_graphic_object*)tf;
case mp_stroked_code:
ts= (mp_stroked_object*)mp_new_graphic_object(mp,mp_stroked_code);
gr_pre_script(ts)= mp_xstrdup(mp,gr_pre_script((mp_stroked_object*)p));
gr_post_script(ts)= mp_xstrdup(mp,gr_post_script((mp_stroked_object*)p));
gr_path_p(ts)= mp_gr_copy_path(mp,gr_path_p((mp_stroked_object*)p));
gr_pen_p(ts)= mp_gr_copy_path(mp,gr_pen_p((mp_stroked_object*)p));
gr_dash_p(ts)= mp_gr_copy_dashes(mp,gr_dash_p(p));

//GMD Graham fixes --------------------------------->
ts->ljoin = ((mp_stroked_object*)p)->ljoin;
ts->color_model = ((mp_stroked_object*)p)->color_model;
ts->miterlim = ((mp_stroked_object*)p)->miterlim;
ts->lcap = ((mp_stroked_object*)p)->lcap;
ts->color_model = ((mp_stroked_object*)p)->color_model;
ts->color.a_val = ((mp_stroked_object*)p)->color.a_val;
ts->color.b_val = ((mp_stroked_object*)p)->color.b_val;
ts->color.c_val = ((mp_stroked_object*)p)->color.c_val;
ts->color.d_val = ((mp_stroked_object*)p)->color.d_val;
q= (mp_graphic_object*)ts;

Tobias Columbus | 16 Oct 23:44 2014

Filling complex paths

Hi all,

I am currently writing a piece of software that should spit out some MetaPost
code. My input are the closed curves of a glyph and I want to produce MetaPost
code that fills them according to Postscript rules. However, as MetaPost cannot
handle non-contiguous closed paths, this task seems difficult at least. 

Note that the glyphs come from non-Postscript fonts, so that the MetaPost
"glyph" primitive does not work for me. I also tried "graphictext" as described
in the Metafun manual but that turned out to be too inaccurate. I traced the
inaccuracy back to "pstoedit", which is called for "graphictext".

My attempt was to fiddle around with specials and
withprescript/withpostscript.  This attempt turned out to be nonsense as
addto always writes "stroke" or "fill" and my specials were ignored. I
could, of course, write the whole glyph with specials, but I would
prefer a cleaner solution.

Has anybody some experience with this kind of problem? How difficult
would it be to add filling of non-contiguous paths to MetaPost?

Thank you in advance,

Vafa Khalighi | 9 Sep 07:09 2014

"Improper transformation argument" Error

I have a metafont source file that has the following code:

  my_T := currenttransform;
  currenttransform := identity slanted my_slant;
  currentpicture := nullpicture;
  picture joined_fit_plus_pic;
  pickup pensquare;
  x1=x2=-2mag;  x3=x4=2mag+kashida_width;
  y1=y4=0;  y2=y3=horiz_width;
 fill (z1--z2--z3--z4--cycle) withweight 1;
  joined_fit_plus_pic := currentpicture;
  currenttransform := my_T;

when I run metafont on this, it runs smoothly without any problems.
but when I use mfplain format of metapost, I get the following error:

>> currenttransform.withweight1
! Improper transformation argument.
<to be read again>
l.61  fill (z1--z2--z3--z4--cycle) withweight 1;


What is wrong? and how do I fix this? If required, I can provide the
full source.