gmane.comp.tex.metapost

Re: mpost assertion failure

Werner LEMBERG — 2013-05-23T10:30:58


Oh, yes, of course!  I was unclear about this.


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

Re: mpost assertion failure

Taco Hoekwater — 2013-05-23T09:34:27

On May 23, 2013, at 10:59 AM, Werner LEMBERG <wl< at >gnu.org> wrote:


Quick reply: I am sure that this bug is completely unrelated. I'll try to write a longer reply later today, but my time is very limited right now, and it seems unlikely that I can fix this in a hurry, sorry.

Best wishes,
Taco



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

Re: mpost assertion failure

Werner LEMBERG — 2013-05-23T08:59:15


Alas, I spoke too soon.  While it doesn't crash any more, some of of
the resulting glyphs are heavily distorted.

Attached are the necessary input files to provide one of those glyphs,
together with mpost's PS output from r26509 (good) and r30634 (bad).
Sorry for not having more time to reduce the sample code even more.

Folks, this isn't production code...


    Werner


PS: Comparing the i386-linux mpost binaries of r26509 (for TeXLive
    2012) and the current one (r30634) I notice that the former has a
    size of about 506kByte, while the latter is almost 13 times
    larger, having 6474kByte!  How comes?  While I agree that disk
    space is cheap today, such an increase looks, well, heavy.


%!PS
%%BoundingBox: -28 0 301 786 
%%HiResBoundingBox: -27.503 0 300.8456 785.82744 
%%Creator: MetaPost 1.504
%%CreationDate: 2013.05.23:1045
%%Pages: 1
%%BeginProlog
%%EndProlog
%%Page: 1 1
% MF2PT1: bbox 0 -160.88312 365.11708 160.88312
% MF2PT1: glyph_dimensions 0 -160.88312 365.11708 160.88312
% MF2PT1: fon

Re: mpost assertion failure

Werner LEMBERG — 2013-05-23T06:30:01


And with rev. 30652, everything works fine again, thanks.


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

Re: [tex-live] mpost assertion failure

Akira Kakuto — 2013-05-20T08:15:34

Dear Werner LEMBERG,


It seems that the w32 binary works for the example.
I attach feta-noteheads11.log.

Best regards,
Akira KAKUTO--
http://tug.org/metapost/

Re: [tex-live] mpost assertion failure

Akira Kakuto — 2013-05-20T08:12:39

Dear Werner LEMBERG,


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

Re: intersectiontimes peculiarity

Boguslaw Jackowski — 2013-04-24T19:35:17


Apologies for providing a "semi-product". :-)


Bravo!

Anyway, the stuff I have sent was meant to be adjusted according to one's 
private preferences -- I should have mention this explicitly.

Cheers -- Jacko

Re: intersectiontimes peculiarity

Troy Henderson — 2013-04-24T13:57:32

Apologies for the excessive responses.  This solution did not work;
however, simply using

numeric p[][];

before redefining p2 did the trick.

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

Re: intersectiontimes peculiarity

Troy Henderson — 2013-04-24T12:56:15

It seems that changing the line in the macro intersect_curves that reads

p1[incr l_]=p_1[k_]+i_; p2[l_]=p_2[k_]+j_;

to

p1[incr l_]:=p_1[k_]+i_; p2[l_]:=p_2[k_]+j_;

(that is, changing both = to := ) fixed that problem of redefining p2.

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

Re: intersectiontimes peculiarity

Troy Henderson — 2013-04-24T11:49:41

How can I redefine one of the paths and call intersect_curves again?  For
example, the following errors due to inconsistent equations.

Troy

--

input intersect_curves;
input quicksort;

beginfig(0);
    u:=28;
    path p[\\];

p1:=(0,0){up}..(1,1){right}..(4,-2){down}..(1,-5){left}..(0,-4){up}..(2,-2){up}..cycle;
    draw p1 scaled u;


    % First choice for p2
    p2:=(1,-5.5)--(1,1.5);
    intersect_curves(p);
    quicksort p2(1,p2num);
    draw p2 scaled u;
    for i=1 upto p2num: fill fullcircle scaled 3 shifted (point p2[i] of p2
scaled u); endfor;

    % Second choice for p2
    p2:=(3,-5.5)--(3,1.5);
    intersect_curves(p);
    quicksort p2(1,p2num);
    draw p2 scaled u;
    for i=1 upto p2num: fill fullcircle scaled 3 shifted (point p2[i] of p2
scaled u); endfor;

endfig;

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

Re: intersectiontimes peculiarity

Troy Henderson — 2013-04-24T11:33:05

Thanks Jacko.  This seems to work nicely.

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

Re: intersectiontimes peculiarity

Boguslaw Jackowski — 2013-04-24T10:47:35


Hi,

needless to say, the subject has appeared a few times on MP list. :-)

Attached is my proposal of finding all intersections (the time-order is 
forced by applying the quicksort method).

One must remember that in discrete geometry one cannot robustly tell 
tangent or almost tangent curves from intersecting ones. Given this 
reservation, the algorithm works quite nicely -- we use it in our engines 
generating fonts for many years.

Cheers -- Jacko

intersectiontimes peculiarity

Troy Henderson — 2013-04-24T09:27:27

I've read Knuth's explanation of how "intersectiontimes" works when two
paths intersect in multiple points (in Chapter 14 of the METAFONTbook), but
I cannot seem to figure out how to FORCE lexicographic ordering of the
intersection times.

For example, if paths p and q intersect in multiple points, I would like
to, somehow, have

(s,whatever) = q intersectiontimes p;

return the "first" (i.e., smallest "time") for q in which q and p
intersect.  This is illustrated in the code below (which generates the
attached figure).

Notice that q intersects p at times (and these times are for q) 0.07144,
0.35716, 0.64287, and 0.92859 which correspond to the points (1,-5),
(1,-3), (1,-1) and (1,1), respectively.  However, the command

(s,whatever) = q intersectiontimes p;

returns the last (namely 0.92859) time for q instead of the first (namely
0.07144) time for the intersection.  Is there a way to FORCE "q
intersectiontimes p" to always return the smallest time for q?

Thanks in advance,

Troy

--

path p,q,r;
p:=(0,0)

Re: point "inside" cycle

Boguslaw Jackowski — 2013-04-23T07:40:09


I believe that the method based on computing a winding number for a given 
point and curve (idea suggested by Larry Siebenmann; described in details
in "Computing the area and winding number for a B\´ezier curve" by B.J.,
http://tug.org/TUGboat/tb33-1/tb103jackowski.pdf ) is sufficiently
efficient and robust for this purpose. Of course, because of general 
problems with discrete geometry, there is an unavoidable problem with 
points nearly touching the curve.

Here you have my implementation that I use in for making fonts:

vardef windingangle(expr p,q) = % |p| -- point, |q| -- B\'ezier segment
  save a,b,v;
  a=length(p-point 0 of q); b=length(p-point 1 of q);
  if min(a,b)<2 eps: % MF and MP are not the masters of precision, we'd 
better stop now
   errhelp "It is rather not advisable to continue. Will return 0.";
   errmessage "windingangle: point unsafely near upon B\'ezier segment 
(dist="
      & decimal(min(a,b)) & ")";
   0
  else:
   v:=mock_arclength(q); % |v| denotes both length and angle
   if

Re: point "inside" cycle

2013-04-23T05:19:41

I don't think there's any easy way that will always be correct.

You can approximate it by testing whether the point is inside the bounding
box of the curve - that is often correct, but of course, not always.

You can draw a path (maybe just a single straight line segment) from z to
some other point that you know is outside; then test whether the new path
intersects with p.  That is very often correct, especially if you check
the bounding box first and maybe try it more than once with a couple of
different known-outside points.  However, it's still vulnerable to false
positives in the case of p being very complicated.

To really get it right you have to first define what you think the "right"
answer actually is; it's not obvious what should or shouldn't count in the
case of self-intersecting figure-8 kinds of curves.  I don't know of a
nice clean simple solution.  Most people make do with approximations.

Re: point "inside" cycle

Werner LEMBERG — 2013-04-23T04:10:59


You might play with the `is_clockwise' macro from the `mf2pt1.mp' file
(in the mf2pt1 package).  It has a different purpose, and you have to
simplify it a lot to start from a given point, but the used algorithm
should work just fine.


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

point "inside" cycle

Troy Henderson — 2013-04-23T01:10:24

Does MetaPost have a clever way of determining whether a point z is
"inside" a closed path (cycle) p?

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

Re: metapost packages

Franck Pastor — 2013-04-08T04:58:12

Le 8 avr. 2013 à 01:14, mv968 <mv968< at >tiscalinet.it> a écrit :


The Comprehensive TeX Archive Network (CTAN) is also dedicated to MetaFont/MetaPost packages.

HTH,

Franck Pastor



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

metapost packages

mv968 — 2013-04-07T23:14:12

Is there a web repository dedicated to Metapost macros/packages?
For example, I need to draw dimensions (a CAD feature): I have to write some macro myself or I am reinventing the wheel? And if I write something worth, how can I share it so to give it good web visibility and let others improve it?
Thanks.

Mario

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

Re: feature request

2013-04-07T14:43:31

Try this.  It's a modification of the rotatedaround macro from mfplain.mp.

def scaledaround(expr z, w) = shifted -z scaled w shifted z enddef;

feature request

mv968 — 2013-04-07T10:08:56

Sorry newbie here. What about a "scaledaround" command? That is scaling 
with the possibility of choosing the origin of scaling. I think it would 
be useful.

Thanks.

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