Here's a problem that I just noticed in the internal mptopdf conversion macros. The fig.1 figure looks fine as a mps (eps) file, and 'mptopdf fig.1' converts it fine. However, including it in a document as fig.1 (hence via the internal mps to pdf conversion) adds strange thick lines to it. Here is the .mp file, and I've attached a complete .zip archive with a .tex file and Makefile to generate the comparison. =========================== fig.mp ================================= % equilateral triangles cut in half % cutter is the path that cuts the triangle in half def half_triangle(text cutter) = path tri, enclosed; z0 = (2cm,0); z1 = z0 rotated 60; tri := origin--z0--z1--origin; enclosed := (cutter)--z1--point 0 of (cutter)--cycle; fill enclosed withcolor 0.65white; draw tri; dotlabel (btex etex, point 0 of (cutter)); dotlabel (btex etex, point 4000 of (cutter)); draw cutter; enddef; % replicate the triangle and path to make hexagon def replicate_six_times = % move triangle so that is at the origin, then shrink it currentpicture := currentpicture shifted (-z1) scaled 0.7; for i = 1 upto 6: draw currentpicture rotated (60*i); endfor enddef; % replicate the triangle bisected by line straight across beginfig(1) half_triangle(point (2+sqrt(0.5)) of tri--point (2-sqrt(0.5)) of tri); replicate_six_times; endfig; end =================================================================== Program versions: pdfTeX, Version 3.141592-1.40.0 (Web2C 7.5.6) ConTeXt ver: 2007.01.12 15:56 MKII fmt: 2007.1.13 int: english/english MPtoPDF 1.3.2 MetaPost 0.993 -Sanjoy `A nation of slaves is always prepared to applaud the clemency of their master who, in the abuse of absolute power, does not proceed to the last extremes of injustice and oppression.' (Gibbon)
Sanjoy Mahajan wrote:
Here's a problem that I just noticed in the internal mptopdf conversion macros. The fig.1 figure looks fine as a mps (eps) file, and 'mptopdf fig.1' converts it fine. However, including it in a document as fig.1 (hence via the internal mps to pdf conversion) adds strange thick lines to it. Here is the .mp file, and I've attached a complete .zip archive with a .tex file and Makefile to generate the comparison.
Same problem here, using 2007.01.18. Taco
Sanjoy Mahajan wrote:
Here's a problem that I just noticed in the internal mptopdf conversion macros. The fig.1 figure looks fine as a mps (eps) file, and 'mptopdf fig.1' converts it fine. However, including it in a document as fig.1 (hence via the internal mps to pdf conversion) adds strange thick lines to it. Here is the .mp file, and I've attached a complete .zip archive with a .tex file and Makefile to generate the comparison.
ok, i fixed it; was a bug in the rline to handler in concat mode in the mkii backend file (mkii and mkiv mp2pdf backends are no longer in sync with mptopdf and somewhat optimized because we no longer need to be generic) btw, the thick lines are actually drawdots btw, your graphic contains 90% junk ps (covered by successive draws), maybe some picture magic without picture resets Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
ok, i fixed it; was a bug in the rline to handler in concat mode
Great, thanks for that.
btw, your graphic contains 90% junk ps (covered by successive draws), maybe some picture magic without picture resets
Indeed, I was surprised by the length of the mps file. Oh, it just
hit me the reason for all the junk ps. It is my 'thinko', so thanks
for pointing me to the problem.
I meant to draw the rotated picture of one triangle six times.
Instead I rotated the currentpicture and drew it on the
currentpicture, so I ended up with 2^6 triangles -- with most of the
code overlapping. It looked right so I didn't think about it enough.
What I had:
currentpicture := currentpicture shifted (-z1) scaled 0.7;
for i = 1 upto 6:
% this line causes the doubling each time
draw currentpicture rotated (60*i);
endfor
Instead, what I should do to avoid the overlapping:
currentpicture := currentpicture shifted (-z1) scaled 0.7;
tpic := currentpicture
for i = 1 upto 5: % i=6 redraws the original one
draw tpic rotated (60*i);
endfor
For those curious about the math behind the picture: The picture
solves the problem of "how do you bisect an equilateral triangle [into
two equal areas] using the shortest path?"
Sanjoy Mahajan wrote:
ok, i fixed it; was a bug in the rline to handler in concat mode
Great, thanks for that.
btw, your graphic contains 90% junk ps (covered by successive draws), maybe some picture magic without picture resets
Indeed, I was surprised by the length of the mps file. Oh, it just hit me the reason for all the junk ps. It is my 'thinko', so thanks for pointing me to the problem.
I meant to draw the rotated picture of one triangle six times. Instead I rotated the currentpicture and drew it on the currentpicture, so I ended up with 2^6 triangles -- with most of the code overlapping. It looked right so I didn't think about it enough.
What I had:
currentpicture := currentpicture shifted (-z1) scaled 0.7; for i = 1 upto 6: % this line causes the doubling each time draw currentpicture rotated (60*i); endfor
Instead, what I should do to avoid the overlapping:
currentpicture := currentpicture shifted (-z1) scaled 0.7; tpic := currentpicture for i = 1 upto 5: % i=6 redraws the original one draw tpic rotated (60*i); endfor
For those curious about the math behind the picture: The picture solves the problem of "how do you bisect an equilateral triangle [into two equal areas] using the shortest path?"
has the details in section 4.5.
or something picture p ; p := image( draw like usual ) ; for ... draw p rotated ... .. ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
Sanjoy Mahajan wrote:
Here's a problem that I just noticed in the internal mptopdf conversion macros. The fig.1 figure looks fine as a mps (eps) file, and 'mptopdf fig.1' converts it fine. However, including it in a document as fig.1 (hence via the internal mps to pdf conversion) adds strange thick lines to it. Here is the .mp file, and I've attached a complete .zip archive with a .tex file and Makefile to generate the comparison.
ok, i fixed it; was a bug in the rline to handler in concat mode in the mkii
This bug is fixed in today's release (uploaded already) Taco
participants (3)
-
Hans Hagen -
Sanjoy Mahajan -
Taco Hoekwater