MetaPost label direction prefix
Hi, what is the reason the label direction prefix variables (rt, bot, llft, etc.) are prefixed with mpfun_ in MkIV (mp-mlib.mpiv)? When new directional prefixes are being defined it fails when mplib is used unless the mpfun_ prefix is added. And likewise, code using the mpfun_ prefix fails on traditional MetaPost. Is this prefix required? It breaks old code and required a branch in every new project. And I don't really see a reason for this incompatibility. Here is an example defining a new direction “foo”: \starttext \startMPcode label("first", origin); %% MkIV %% pair mfun_laboff.foo ; mfun_laboff.foo := (.5,-1) ; %% mfun_labxf.foo := mfun_labyf.foo := 1 ; %% MkII pair laboff.foo ; laboff.foo := (.5,-1) ; labxf.foo := labyf.foo := 1 ; label.foo("second", origin); \stopMPcode \stoptext Marco
On 8/23/2013 11:42 AM, Marco Patzer wrote:
Hi,
what is the reason the label direction prefix variables (rt, bot, llft, etc.) are prefixed with mpfun_ in MkIV (mp-mlib.mpiv)? When new directional prefixes are being defined it fails when mplib is used unless the mpfun_ prefix is added. And likewise, code using the mpfun_ prefix fails on traditional MetaPost.
So is anyone using mkiv still using MkII?
Is this prefix required? It breaks old code and required a branch in every new project. And I don't really see a reason for this incompatibility. Here is an example defining a new direction “foo”:
The MpIV code has namespace protection. Why run traditional in MkIV?
\starttext \startMPcode label("first", origin);
%% MkIV %% pair mfun_laboff.foo ; mfun_laboff.foo := (.5,-1) ; %% mfun_labxf.foo := mfun_labyf.foo := 1 ;
%% MkII pair laboff.foo ; laboff.foo := (.5,-1) ; labxf.foo := labyf.foo := 1 ;
label.foo("second", origin); \stopMPcode \stoptext
I wasn't aware of users defining extra ones. I'll add this: \starttext \startMPcode label("first", origin); if known mfun_laboff : vardef installlabel@\# (expr type, x, y, offset) = numeric mfun_labtype @\# ; mfun_labtype @\# := type ; pair mfun_laboff @\# ; mfun_laboff @\# := offset ; numeric mfun_labxf @\# ; mfun_labxf @\# := x ; numeric mfun_labyf @\# ; mfun_labyf @\# := y ; enddef ; else : vardef installlabel@\# (expr type, x, y, offset) = numeric labtype @\# ; labtype @\# := type ; pair laboff @\# ; laboff @\# := offset ; numeric labxf @\# ; labxf @\# := x ; numeric labyf @\# ; labyf @\# := y ; enddef ; fi ; installlabel.foo ( 0, 1, 1, (.5,-1) ) ; label.foo("second", origin); \stopMPcode \stoptext ----------------------------------------------------------------- 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 -----------------------------------------------------------------
On 2013–08–23 Hans Hagen wrote:
Is this prefix required? It breaks old code and required a branch in every new project. And I don't really see a reason for this incompatibility. Here is an example defining a new direction “foo”:
The MpIV code has namespace protection. Why run traditional in MkIV?
\starttext \startMPcode label("first", origin);
%% MkIV %% pair mfun_laboff.foo ; mfun_laboff.foo := (.5,-1) ; %% mfun_labxf.foo := mfun_labyf.foo := 1 ;
%% MkII pair laboff.foo ; laboff.foo := (.5,-1) ; labxf.foo := labyf.foo := 1 ;
label.foo("second", origin); \stopMPcode \stoptext
I wasn't aware of users defining extra ones. I'll add this:
Probably not many users will tinker with custom label directions, but MetaPost package authors do. Some packages like piechartmp¹ internally use laboff.foo and the mpfun_ prefix breaks those packages. They work in traditional MetaPost, plain TeX, LaTeX and ConTeXt MkII, but since mplib uses the mpfun_ prefix, those packages are broken in MkIV.
[…] installlabel.foo ( 0, 1, 1, (.5,-1) ) ;
This does not fix the problem since it only *defines* the correct variant, it doesn't help *using* those values. If the label values are being changed in the package one still has to branch out to support both variants. And even if there was an abstraction assisting to *use* the laboff values, all MetaPost packages tinkering with laboff would need to be adjusted. I can't imagine that to happen. Here's what the piechartmp package is doing, for instance: if laboff.@# = (-3,-3): % auto justification […] laboff.auto := ((cosd l),(sind l)) ; labxf.auto := ((cosd l) - 1) / -2 ; labyf.auto := ((sind l) - 1) / -2 ; […] This code is being executed every time a label is typeset. Marco ¹ http://mirrors.ctan.org/graphics/metapost/contrib/macros/piechartmp/piechart...
On 8/23/2013 3:14 PM, Marco Patzer wrote:
On 2013–08–23 Hans Hagen wrote:
Is this prefix required? It breaks old code and required a branch in every new project. And I don't really see a reason for this incompatibility. Here is an example defining a new direction “foo”:
The MpIV code has namespace protection. Why run traditional in MkIV?
\starttext \startMPcode label("first", origin);
%% MkIV %% pair mfun_laboff.foo ; mfun_laboff.foo := (.5,-1) ; %% mfun_labxf.foo := mfun_labyf.foo := 1 ;
%% MkII pair laboff.foo ; laboff.foo := (.5,-1) ; labxf.foo := labyf.foo := 1 ;
label.foo("second", origin); \stopMPcode \stoptext
I wasn't aware of users defining extra ones. I'll add this:
Probably not many users will tinker with custom label directions, but MetaPost package authors do. Some packages like piechartmp¹ internally use laboff.foo and the mpfun_ prefix breaks those packages. They work in traditional MetaPost, plain TeX, LaTeX and ConTeXt MkII, but since mplib uses the mpfun_ prefix, those packages are broken in MkIV.
that kind of tinkering can also result in overloading context 'extensions'
[…] installlabel.foo ( 0, 1, 1, (.5,-1) ) ;
This does not fix the problem since it only *defines* the correct variant, it doesn't help *using* those values. If the label values are being changed in the package one still has to branch out to support both variants. And even if there was an abstraction assisting to *use* the laboff values, all MetaPost packages tinkering with laboff would need to be adjusted. I can't imagine that to happen. Here's what the piechartmp package is doing, for instance:
I'll provide: \starttext \startMPcode startplaincompatibity ; label("first", origin); pair laboff.foo ; laboff.foo := (.5,-1) ; labxf.foo := labyf.foo := 1 ; label.foo("second", origin); stopplaincompatibity ; \stopMPcode \stoptext As I wouldn't be surprised if there were more differences we need to handle. 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 -----------------------------------------------------------------
On 2013–08–24 Hans Hagen wrote:
startplaincompatibity ;
label("first", origin);
pair laboff.foo ; laboff.foo := (.5,-1) ; labxf.foo := labyf.foo := 1 ;
label.foo("second", origin);
stopplaincompatibity ;
Brilliant! Thanks a lot. A few things: 1) Can you replace def useplainlabels = let label = plain_label ; let thelabel = plain_thelabel ; enddef ; with def useplainlabels = def label = plain_label enddef ; def thelabel = plain_thelabel enddef ; enddef ; The minimal example works with your version, but the old MetaPost code does not. The def variant works fine with both. 2) Replace startplaincompatibity → startplaincompatibility stopplaincompatibity → stopplaincompatibility 3) This one is truly optional and just a suggestion for a better interface. Although it's nice to have the grouping in start-stopplaincompatibility, it's not required here, since the entire MetaPost instance runs in plain compatibility mode. It would be nice to either have a non-grouped command: def plaincompatibility = scantokens plain_compatibity_data ; enddef ; Or maybe even a higher-level switch: \defineMPinstance [fun-with-old-MP] [metafun] [compatibility=plain] %% default* | plain
As I wouldn't be surprised if there were more differences we need to handle.
We will find out if things break. Marco
On 8/24/2013 2:31 PM, Marco Patzer wrote:
On 2013–08–24 Hans Hagen wrote:
startplaincompatibity ;
label("first", origin);
pair laboff.foo ; laboff.foo := (.5,-1) ; labxf.foo := labyf.foo := 1 ;
label.foo("second", origin);
stopplaincompatibity ;
Brilliant! Thanks a lot. A few things:
1) Can you replace
def useplainlabels = let label = plain_label ; let thelabel = plain_thelabel ; enddef ;
with
def useplainlabels = def label = plain_label enddef ; def thelabel = plain_thelabel enddef ; enddef ;
The minimal example works with your version, but the old MetaPost code does not. The def variant works fine with both.
ok
2) Replace
startplaincompatibity → startplaincompatibility stopplaincompatibity → stopplaincompatibility
ok, best check the next beta well (i might have missed some)
3) This one is truly optional and just a suggestion for a better interface. Although it's nice to have the grouping in start-stopplaincompatibility, it's not required here, since the entire MetaPost instance runs in plain compatibility mode. It would be nice to either have a non-grouped command:
def plaincompatibility = scantokens plain_compatibity_data ; enddef ;
due to the way grouping works in mp it doesn't hurt to have it and by using it we can avoid a push/pop stack after all in the end we want to go back to the metafun labels
Or maybe even a higher-level switch:
\defineMPinstance [fun-with-old-MP] [metafun] [compatibility=plain] %% default* | plain
As I wouldn't be surprised if there were more differences we need to handle.
maybe later
We will find out if things break.
indeed 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 -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Marco Patzer