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: Directory management in Metapost
http://permalink.gmane.org/gmane.comp.tex.metapost/2680
<pre>
yes, currently
} else if (ARGUMENT_IS("translate-file") ||
ARGUMENT_IS("output-directory") ||
ARGUMENT_IS("no-parse-first-line")) {
fprintf(stdout,"warning: %s: unimplemented option %s\n", argv[0],
argv[optind]);
I will see it asap.
</pre>luigi scarso2015-11-19T14:28:11Directory management in Metapost
http://permalink.gmane.org/gmane.comp.tex.metapost/2679
<pre>Hi,
It seems that Metapost doesn't recognize folder paths, or in command line
terms, doesn't obey the -output-directory. This makes it impossible to call
it on files that are located in different folders.
As an example/illustration of this issue, it restricts the file management
in drawing diagrams in LaTeX (see e.g.
http://tex.stackexchange.com/questions/279009/save-feynman-diagram-files-in-a-subfolder
).
Kind regards,
Tom Vethaak
--
http://tug.org/metapost/</pre>Tom Vethaak2015-11-19T13:56:44Re: Long numerical tokens with new number systems
http://permalink.gmane.org/gmane.comp.tex.metapost/2678
<pre>
Rev. 2070 has now a patch based on
"27 bits are not enough for 8-digit accuracy" by I. Bennett Goldberg
</pre>luigi scarso2015-10-06T10:43:01Re: metapost tfm bug with mfplain
http://permalink.gmane.org/gmane.comp.tex.metapost/2677
<pre>luigi scarso napsal(a):
Dear Luigi,
perhaps it could help that the >last stable< version 1.212 gives correct
metrics:-)
Karel
--
http://tug.org/metapost/</pre>Karel Horák2015-09-02T10:20:02Re: metapost tfm bug with mfplain
http://permalink.gmane.org/gmane.comp.tex.metapost/2676
<pre>On Mon, Aug 17, 2015 at 8:03 PM, Daniel H. Luecking <luecking< at >uark.edu>
wrote:
</pre>luigi scarso2015-09-02T09:12:17Re: 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:44Search EngineSearch the mailing list at Gmanequery
http://search.gmane.org/?group=$group=gmane.comp.tex.metapost