pair)
> > I don't know, but from the message it looks like some 'local'
> variables
> > is not saved and defined. I'm surprised that loading some mf file
> works
> > at all (because it also assumes some mf related definitions). I also
> > hav
&g
nitions). I also
hav
eno clue if such a package adopts 'core' metafun code (and mpiv metafun
is different from mpii).
It's a generic, "pure" MetaPost package:
https://www.ctan.org/pkg/cmarrows <https://www.ctan.org/pkg/cmarrows>
that doesn't make
I don't know, but from the message it looks like some 'local' variables
> is not saved and defined. I'm surprised that loading some mf file works
> at all (because it also assumes some mf related definitions). I also hav
> eno clue if such a package adopts 'core'
v
eno clue if such a package adopts 'core' metafun code (and mpiv metafun
is different from mpii).
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasse
Hi,
The 2021 texlive code is currently being frozen. This means that Mojca
will check-in the current context release right before tl gets deep frozen.
The MKII code (mkii and mpii files) hasn't changed so it should still
work well with pdftex and xetex although I admit that I haven'
tion); also, when making vardef's one need to omit the final
semi colon in order to apply more properties to the 'return value'.
At some point I will update the metafun manual which means: remove old
methods and exclusively use the new ones (currently the manual also
discusses
5
**\relax; tracingall; input test.mp;
(/usr/local/texlive/2018/texmf-dist/metapost/context/base/common/metafun.mp
(/usr/local/texlive/2018/texmf-dist/metapost/context/base/mpii/metafun.mpii
(/usr/local/texlive/2018/texmf-dist/metapost/context/base/mpii/mp-base.mpii
Preloading the plain mem file,
On 10/1/2013 8:35 PM, Marco Patzer wrote:
On 2013–10–01 Hans Hagen wrote:
in mkiv the overhead is less than in mpii as we don't parse the blob
in the same way and the mpiv code is also more optimized so we can
consider dropping the SetPageState macro.
I see you decided to drop LoadPage
On 2013–10–01 Hans Hagen wrote:
> in mkiv the overhead is less than in mpii as we don't parse the blob
> in the same way and the mpiv code is also more optimized so we can
> consider dropping the SetPageState macro.
I see you decided to drop LoadPageState. It's about 20m
s)
% system > starting feature test
% system > feature test done (0.001s)
% system > starting feature test
% system > feature test done (0.002s)
\stoptext
in mkiv the overhead is less than in mpii as we don't parse the blob in
the same way and the mpiv cod
gt;(/tmp/mkiitest/tex/texmf-context/metapost/context/base/mp-func.mpii) ) )
> > >(end occurred when else on line 5 was incomplete)
> >
> > That's not mkii but the metafun mpii format generation. I kept that
> > till now because one never knows is mp has been updated
)
> >(end occurred when else on line 5 was incomplete)
>
> That's not mkii but the metafun mpii format generation. I kept that
> till now because one never knows is mp has been updated. Todays
> mpost has no format so that's why it looks like it 'fails' but c
:
…
(/tmp/mkiitest/tex/texmf/metapost/base/string.mp
(/tmp/mkiitest/tex/texmf-context/metapost/context/base/mp-func.mpii) ) )
(end occurred when else on line 5 was incomplete)
That's not mkii but the metafun mpii format generation. I kept that till
now because one never knows is mp ha
-ini.mkiv delete these lines:
>
>
> \startMPextensions
> if unknown context_tool: input mp-tool; fi;
> if unknown context_spec: input mp-spec; fi;
> if unknown context_grph: input mp-grph; fi;
> \stopMPextensions
>
&
;
\stopMPextensions
(as it load the mpii spec file which redefines transparency to use old
trickery)
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The
I made a patch (at the mp macro level) for the backgrounds but more
placed might need patching. So, from now on we will also have different
files for mp: mpii and mpiv.
I uploaded a beta, so best do some testing right aw
16 matches
Mail list logo