gmane.comp.tex.metapost
http://blog.gmane.org/gmane.comp.tex.metapost
hourly11901-01-01T00:00+00:00Gmanehttp://gmane.org/img/gmane-25t.png
http://gmane.org
Re: metapost tfm bug with mfplain
http://permalink.gmane.org/gmane.comp.tex.metapost/2675
<pre>Karel:
Metapost and Metafont are using different resolution values.
Metafont uses the resolution of localfont, which is 600dpi on
my system. Mfplain uses an effective resolution of 3600dpi. This
produces much larger pixel values. A lower value of u# in your
file should have the same effect as reducing the resolution.
However, a few tests with u# = (1/6)mm# produce the same problem.
I am forced to agree that there is a bug either in mfplain.mp or
in metapost itself (or perhaps it is in me).
Regards,
Daniel H. Luecking [luecking< at >uark.edu]
Graduate Coordinator
Department of Mathematical Sciences
1 University of Arkansas
Fayetteville, AR, USA 72701-1201
________________________________
From: Karel Horák <horakk< at >math.cas.cz>
Sent: Monday, August 17, 2015 12:15 PM
To: Daniel H. Luecking
Cc: metapost< at >tug.org
Subject: Re: [metapost] metapost tfm bug with mfplain
Daniel H. Luecking napsal(a):
Karel <horakk< at >math.cas.cz><mailto:horakk< at >math.cas.cz> wrote:
To make things easier, I changed all the graphics into trivial
rectangles, the incorrect dimensions are still there in case of chars 44
and 45 (octal 36 and 37). The height of these two characters is much
smaller than their width but should be higher!
I think you mean octal 44 and 45 (which are decimal 36 and 37).
It depends on the reading, I wanted to say octals of decimals 36 and 37 :-)
I'm just guessing here, but when metaFONT writes a tfm file, all the
dimensions are required to be less than 4096.0. It is possible metaPOST
uses the same code for creating the tfm file and makes the same
requirement. In character 36,
show h;
produces 7935.29486. It is possible that bits above the twefth are
ignored and so 7935.29486 - 4096 = 3839.29486 would be used. Or it
is possible some other truncation method is used.
There is another factor that might be at work here: there is a limit on
the number of different character heights there can be in a tfm file. If
there are more than 15, some will be adjusted so that there are only 15.
Your file seems to have 18 different heights. A similar limit is imposed on
depths and widths.
You are of course true, but metafont gives correct tfm with some changes of heights but those are neglectable (some charht values had to be adjusted by as much as 1.10536pt). On the other hand metapost does not give any information about changing the heights at all.
Originally I generated metrics with metafont but preparing now a new edition of textbook I thought that it is not more necessary to compile the source twice:-)
All the best,
Karel
--
http://tug.org/metapost/</pre>Daniel H. Luecking2015-08-17T18:03:51Re: metapost tfm bug with mfplain
http://permalink.gmane.org/gmane.comp.tex.metapost/2674
<pre>Daniel H. Luecking napsal(a):
It depends on the reading, I wanted to say octals of decimals 36 and 37 :-)
You are of course true, but metafont gives correct tfm with some changes
of heights but those are neglectable (some charht values had to be
adjusted by as much as 1.10536pt). On the other hand metapost does not
give any information about changing the heights at all.
Originally I generated metrics with metafont but preparing now a new
edition of textbook I thought that it is not more necessary to compile
the source twice:-)
All the best,
Karel
--
http://tug.org/metapost/</pre>Karel Horák2015-08-17T17:15:35Re: metapost tfm bug with mfplain
http://permalink.gmane.org/gmane.comp.tex.metapost/2673
<pre>
I think you mean octal 44 and 45 (which are decimal 36 and 37).
I'm just guessing here, but when metaFONT writes a tfm file, all the
dimensions are required to be less than 4096.0. It is possible metaPOST
uses the same code for creating the tfm file and makes the same
requirement. In character 36,
show h;
produces 7935.29486. It is possible that bits above the twefth are
ignored and so 7935.29486 - 4096 = 3839.29486 would be used. Or it
is possible some other truncation method is used.
There is another factor that might be at work here: there is a limit on
the number of different character heights there can be in a tfm file. If
there are more than 15, some will be adjusted so that there are only 15.
Your file seems to have 18 different heights. A similar limit is imposed on
depths and widths.
Good luck,
Daniel H. Luecking [luecking< at >uark.edu]
Graduate Coordinator
Department of Mathematical Sciences
1 University of Arkansas
Fayetteville, AR, USA 72701-1201
________________________________________
From: metapost <metapost-bounces< at >tug.org> on behalf of Karel <horakk< at >math.cas.cz>
Sent: Monday, August 17, 2015 6:27 AM
To: Akira Kakuto
Cc: metapost< at >tug.org
Subject: [metapost] metapost tfm bug with mfplain
Recently I have found some bug when using metapost with old mf files: in
one case I have get incorrect tfm metrics when compiling with mpost
-mem=mfplain option.
To make things easier, I changed all the graphics into trivial
rectangles, the incorrect dimensions are still there in case of chars 44
and 45 (octal 36 and 37). The height of these two characters is much
smaller than their width but should be higher!
I am adding the source file uceb.mf, the resulting uceb.tfm and the
corresponding u.pl
(resulting from tftopl uceb u).
I used the latest binaries for win64 (metapost 1.999).
Thanks for investigation!
Karel Horak
--
http://tug.org/metapost/
</pre>Daniel H. Luecking2015-08-17T16:24:49Re: Long numerical tokens with new number systems
http://permalink.gmane.org/gmane.comp.tex.metapost/2672
<pre>On Mon, Aug 17, 2015 at 8:11 AM, Akira Kakuto <kakuto< at >fuk.kindai.ac.jp>
wrote:
yes, I will fix it asap (next week, I don't think to find the time now)
</pre>luigi scarso2015-08-17T12:22:08metapost tfm bug with mfplain
http://permalink.gmane.org/gmane.comp.tex.metapost/2671
<pre>Recently I have found some bug when using metapost with old mf files: in
one case I have get incorrect tfm metrics when compiling with mpost
-mem=mfplain option.
To make things easier, I changed all the graphics into trivial
rectangles, the incorrect dimensions are still there in case of chars 44
and 45 (octal 36 and 37). The height of these two characters is much
smaller than their width but should be higher!
I am adding the source file uceb.mf, the resulting uceb.tfm and the
corresponding u.pl
(resulting from tftopl uceb u).
I used the latest binaries for win64 (metapost 1.999).
Thanks for investigation!
Karel Horak
mode=localfont;
mode_setup;
u#:=1mm#;
Pt#:=1pt#;
define_pixels(u,Pt);
warningcheck:=0;
% input labtex
def labtex (text cosi)= enddef;
vardef tg primary x=sind x/cosd x enddef;
beginchar(1,15u#,3*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(2,15u#,5*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(3,15u#,7*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(4,15u#,6*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(5,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
labtex(for k=0 upto 3: .35w*dir(-90k), endfor);
endchar;
beginchar(6,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
labtex(for k=0 upto 3: .35w*dir(-90k), endfor);
endchar;
beginchar(7,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
labtex(for k=0 upto 3: .35w*dir(-90k), endfor);
endchar;
beginchar(8,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(9,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(10,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(11,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(12,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(13,14*4u#,10*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(14,30u#,30u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(15,35u#,30u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(16,50u#,35u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(17,30u#,20u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(18,24u#,20u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(19,36u#,7u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(20,36u#,40u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(21,30u#,.5*30u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(22,30u#,.5*30u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(23,20u#,.5*30u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(24,15u#,15u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(25,30u#,15u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(26,30u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(27,10u#,15u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(28,2*10u#,2*10u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(29,2*10u#,2*10u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(30,2*10u#,2*10u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(31,20u#,.5sqrt3*20u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(32,40u#,.5sqrt3*20u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(33,1/sind36*20u#,(1/(2sind36)+1/(2tg36))*20u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(34,2*8u#,2*8u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(35,2*8u#,2*8u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(36,3*8u#,7*8u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(37,3*8u#,7*8u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(38,2*4u#,6.5*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(39,2*4u#,6.5*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(40,2*4u#,6.5*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(41,2*4u#,6.5*5u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(42,2*4u#,4u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(43,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(44,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(45,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(46,18u#,18u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(47,20u#,20u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(48,20u#,20u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(49,20u#,20u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(50,15u#,15u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(51,15u#,15u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(52,15u#,15u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(53,15u#,15u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(54,2.5*15u#,15u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(55,4sqrt3*6u#,2*6u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(56,3sqrt3*6u#,5*6u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(57,(3sqrt3+3)*6u#,2*6u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(58,6*6u#,1*6u#,0);
draw unitsquare xscaled w yscaled h;
endchar;
beginchar(59,20u#,20u#,0);
draw unitsquare scaled h;
endchar;
end.
--
http://tug.org/metapost/</pre>Karel2015-08-17T11:27:02Long numerical tokens with new number systems
http://permalink.gmane.org/gmane.comp.tex.metapost/2670
<pre>
I find
< at > Precision check is TODO
< at >d too_precise(a) 0
in mpmathbinary.w, while
< at >d too_precise(a) (a == (DEC_Inexact+DEC_Rounded))
in mpmathdecimal.w.
Luigi?
</pre>Akira Kakuto2015-08-17T06:11:14Long numerical tokens with new number systems
http://permalink.gmane.org/gmane.comp.tex.metapost/2669
<pre>The syntax for <numeric token> that MP inherits from Metafont allows for "one or more" decimal digits in the fractional part of a number. So it's legal to write:
numeric pi;
pi = 3.141592653589793238462643383279502884197169399375105820974944592;
show pi;
This works ok with all the number systems except "decimal" which complains about excessive precision.
Here's what I get with each number system
! Number is too precise (numberprecision = 34).
l.80 ...643383279502884197169399375105820974944592
;
?
Doesn't this behaviour seem to be a bit inconsistent?
Clearly, with decimal it would be possible to avoid the error message by writing this sort of thing:
if numbersystem="decimal": numberprecision := 64; fi
before defining the constant, but it would be nice to have a consistent syntax across all number systems.
One other thing that I notice is that the final digit rounding looks wrong for double and binary.
Any comments?
Thanks, Toby
--
http://tug.org/metapost/
</pre>Toby Thurston2015-08-15T19:52:11Re: mpost or luamplib ?
http://permalink.gmane.org/gmane.comp.tex.metapost/2668
<pre>Le 14 août 2015 19:43, "Dohyun Kim" <nomosnomos< at >gmail.com> a écrit :
Ok. Thank you very much.
</pre>Olivier Péault2015-08-15T10:02:44Re: mpost or luamplib ?
http://permalink.gmane.org/gmane.comp.tex.metapost/2667
<pre>2015-08-15 0:47 GMT+09:00 Olivier Péault <o.peault< at >gmail.com>:
Yes, it is reliable... only when you use TeX Live 2013 (or MikTeX
2013) or later, because the boolean `mplib' was first introduced into
luamplib v2.0 released in May 2013.
</pre>Dohyun Kim2015-08-14T17:43:56Re: mpost or luamplib ?
http://permalink.gmane.org/gmane.comp.tex.metapost/2666
<pre>Le 13/08/2015 18:04, Hans Hagen a écrit :
Thanks for the answer.
The real problem is that I have a set of personal macros which must
behave differently when I use luamplib rather than mpost directly. I was
then looking for a test which could give me the answer. I found the
boolean mplib but I don't know if it always exists and is set to true
when the code is processed by luamplib (in my tests, it works, but...).
Anyone can confirm it works?
Thanks for all
</pre>Olivier Péault2015-08-14T15:47:23Re: mpost or luamplib ?
http://permalink.gmane.org/gmane.comp.tex.metapost/2665
<pre>
if you run from within tex it's probably using the lib (i don't know
luamplib but the name suggests that it uses th elib)
you can test it by processing 100 graphics that draw a circle: if it
takes seconds then you're probably not using the lib
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------
--
http://tug.org/metapost/
</pre>Hans Hagen2015-08-13T16:04:47mpost or luamplib ?
http://permalink.gmane.org/gmane.comp.tex.metapost/2664
<pre>Hello!
I'm looking for a way to know whether my metapost code is processed by
metapost itself or by luamplib in lualatex. Reading the luamplib code
(which I don't understand!!!) I found that the boolean mplib could do
the job. Is it right ? Can I be sure that if mplib exists and is true,
my code is processed by luamblib ?
Thank you in advance
</pre>Olivier Péault2015-08-13T15:09:47Re: A modest proposal
http://permalink.gmane.org/gmane.comp.tex.metapost/2663
<pre>
scaled is still the official standard mode but you can make a (local)
file that overloads settings that you can load after plain is loaded
</pre>Hans Hagen2015-08-04T17:54:12Re: A modest proposal
http://permalink.gmane.org/gmane.comp.tex.metapost/2662
<pre>Hm, I tend to consider plain.mp kind of frozen --- I think it could be
still in use for TAOCP, for example. Better to think to a newplain.mp
instead, or something similar.
</pre>luigi scarso2015-08-04T16:03:23A modest proposal
http://permalink.gmane.org/gmane.comp.tex.metapost/2661
<pre>Now that the higher precision number systems are maturing, and being used more, it might be a good time to update "plain.mp" to remove the hard coded 5-figure decimals. In all cases it's fairly easy to find an equivalent definition which would work accurately at full numeric precision regardless of which engine is being used.
The values I can see are
The definition of epsilon shows us a better way
Adopting that strategy we can write the following which work well regardless of number system
eps := 1/2048;
infinity := 64*64-epsilon;
The units require a little bit more thought (and a quick reference to the Texbook for "dd"), but nevertheless here are some exact definitions that would also work with all number systems
1 = 1 bp;
72 = 1 in;
800 = 803 pt;
360 = 127 mm;
3600 = 127 cm;
1 pc = 12 pt;
1 cc = 12 dd;
1157 dd = 1238 pt;
Finally for magstep we could have
vardef magstep primary m = mexp(mlog(1.2)*m) enddef;
Any thoughts? Could these be changes in the next version of plain.mp?
Toby T.
--
http://tug.org/metapost/
</pre>Toby Thurston2015-08-04T15:41:01Bug with simple number comparisons with new numbersystems
http://permalink.gmane.org/gmane.comp.tex.metapost/2660
<pre>Hi,
The present trunk version, changed after the report by Daniel H. Luecking
gives:
Thanks,
</pre>Akira Kakuto2015-07-30T08:44:44Re: Bug with simple number comparisons with new numbersystems
http://permalink.gmane.org/gmane.comp.tex.metapost/2659
<pre>
Thank you for the report, I will investigate soon.
</pre>luigi scarso2015-07-28T07:53:01Bug with simple number comparisons with new numbersystems
http://permalink.gmane.org/gmane.comp.tex.metapost/2658
<pre>I'm getting strange results comparing numbers with the new number systems.
Consider this program:
show 0.0001 < 0.001, numbersystem, mpversion; end.
With the default number system this gives
on my log. But with the other number systems I get:
which is a bit unexpected...
I'm using a version I compiled myself from source after you fixed the normaldeviate bug a couple of months ago.
Testing with V1.902, the only other version I have on hand, I only get the error with "decimal". But it does not appear to matter what numbers I use. I get the same results with "1<2", or "1/4<1/2", etc
This is MetaPost, version 1.902 (TeX Live 2014) (kpathsea version 6.2.0)
This is MetaPost, version 1.902 (TeX Live 2014) (kpathsea version 6.2.0)
This is MetaPost, version 1.902 (TeX Live 2014) (kpathsea version 6.2.0)
This is MetaPost, version 1.902 (TeX Live 2014) (kpathsea version 6.2.0)
I've posted an entry on the tracker. Toby
--
http://tug.org/metapost/
</pre>Toby Thurston2015-07-28T07:21:55Re: Change in behavior of booleans withnumbersystem=decimal
http://permalink.gmane.org/gmane.comp.tex.metapost/2657
<pre>On Wed, Jun 3, 2015 at 12:16 AM, Daniel H. Luecking <luecking< at >uark.edu>
wrote:
</pre>luigi scarso2015-06-02T22:29:34Change in behavior of booleans with numbersystem=decimal
http://permalink.gmane.org/gmane.comp.tex.metapost/2656
<pre>Dear Metapostals:
I don't know whether --numbersystem=decimal is considered
ready to use, but I have observed some odd behavior for the
following file:
%test.mp
show known (0,0,.5,.5);
show cmykcolor (0,0,.5,.5);
end
The command
mpost test
returns true and true, but the command
mpost --numbersystem=decimal test
returns false and false. This is causing mfpic to fail when
the decimal numbersystem is used.
The fact that these are cmykcolor values seems to be irrelevant.
I get similar behavior with pairs and paths. The boolean
"known X" simply seems to not work. Also the booleans
"cmykcolor X", "pair X" and "path X" (those are the only
ones I've tried so far).
I'm using MetaPost, version 1.999 (TeX Live 2015/W32TeX)
under windows 7.
Thanks,
Daniel H. Luecking [luecking< at >uark.edu]
Graduate Coordinator
Department of Mathematical Sciences
1 University of Arkansas
Fayetteville, AR, USA 72701-1201
--
http://tug.org/metapost/</pre>Daniel H. Luecking2015-06-02T22:16:10Re: Stroke Font
http://permalink.gmane.org/gmane.comp.tex.metapost/2655
<pre>Le 16/05/2015 15:37, Troy Henderson a écrit :
Hello,
Given a stroked token tkn within a btex/etex picture,
1. is it always the case that tkn is stroked with linecap set to butt ?
2. If not, is there a way to get a 'linecappart' from tkn ?
3. Then, if linecap is set correctly, can I always expect 'fill envelope
(makepen makepath penpart tkn) of pathpart tkn' to look like tkn ?
Regards,
Laurent Méhats
--%<-- oln-test.mp
verbatimtex%&latex
\documentclass{article}
\usepackage[T1]{fontenc}
%\usepackage{cmbright}
%\usepackage{fourier}
%\usepackage{arev}
\begin{document}
etex;
vardef oln_init (suffix glp_num, pth_num, glp_pth, stk_num, stk_vlp) expr pct=
% pct btex .. etex material
% glp_num number of glyphs within pct
% pth_num[i] number of paths defining the rank i glyph
% (i ranges from 0 to glp_num-1)
% glp_pth[i][j] rank j path of the rank i glyph
% (j ranges from 0 pth_num[i]-1)
% stk_num number of stroked lines within pct
% stk_vlp[i] rank i envelope
% (i ranges from 0 to stk_num-1)
interim linecap:=butt;
glp_num:=0;
stk_num:=0;
for tkn within pct:
if textual tkn:
string fnt_str, txt_str, sub_str;
transform trn;
numeric txt_wd, pth_idx;
picture sub_pct;
fnt_str:=fontpart tkn;
txt_str:=textpart tkn;
(0, 0) transformed trn=(xpart tkn, ypart tkn);
(0, 1) transformed trn=(xpart tkn+xypart tkn, ypart tkn+yypart tkn);
(1, 0) transformed trn=(xpart tkn+xxpart tkn, ypart tkn+yxpart tkn);
txt_wd:=0;
for glp_idx=0 upto (length txt_str-1):
sub_str:=substring (glp_idx, glp_idx+1) of txt_str;
sub_pct:=sub_str infont fnt_str;
pth_idx:=0;
for sub_tkn within glyph ASCII sub_str of fnt_str
scaled (fontsize fnt_str/1000)
shifted (txt_wd, 0)
transformed trn:
glp_pth[glp_num][pth_idx]:=pathpart sub_tkn;
pth_idx:=pth_idx+1;
endfor
txt_wd:=txt_wd+xpart (urcorner sub_pct-llcorner sub_pct);
pth_num[glp_num]:=pth_idx;
glp_num:=glp_num+1;
endfor
elseif stroked tkn:
stk_vlp[stk_num]:=envelope (makepen makepath penpart tkn) of pathpart
tkn;
stk_num:=stk_num+1;
fi
endfor
enddef;
vardef oln_draw (expr pct) text opt=
numeric glp_num, pth_num[], stk_num;
path glp_pth[][], stk_vlp[];
oln_init (glp_num, pth_num, glp_pth, stk_num, stk_vlp) pct;
for glp_idx=0 upto glp_num-1:
for pth_idx=0 upto pth_num[glp_idx]-1:
draw glp_pth[glp_idx][pth_idx] opt;
endfor
endfor
for stk_idx=0 upto stk_num-1:
draw stk_vlp[stk_idx] opt;
endfor
enddef;
picture pct;
pct:=btex$\displaystyle\left(\sqrt{\frac{\sqrt{123}}{\sqrt{a}}}\right\}$etex
rotated 15 scaled 10;
beginfig(0)
oln_draw (pct);
endfig;
beginfig(1)
oln_draw (pct) withpen pencircle scaled 2;
draw pct withcolor (0.7, 0.7, 0.7);
endfig;
beginfig(2)
oln_draw (pct) withpen pencircle scaled 2 dashed evenly;
draw pct withcolor (0.7, 0.7, 0.7);
endfig;
beginfig(3)
draw pct withcolor (0.7, 0.7, 0.7);
oln_draw (pct) withpen pencircle dashed evenly;
endfig;
end
--%<-- oln-test.mp
--
http://tug.org/metapost/
</pre>Laurent Méhats2015-05-31T13:45:18Search EngineSearch the mailing list at Gmanequery
http://search.gmane.org/?group=$group=gmane.comp.tex.metapost