From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/97130 Path: news.gmane.org!.POSTED!not-for-mail From: Sergey Slyusarev Newsgroups: gmane.comp.tex.context Subject: Re: Bug: \textext inside \*MPinclusions causes error Date: Sun, 22 Jan 2017 00:13:00 +0300 Message-ID: References: <5ff6c190-3493-e46a-2fa9-909cb1abb3c8@wxs.nl> Reply-To: mailing list for ConTeXt users NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6054716789549127667==" X-Trace: blaine.gmane.org 1485072495 12817 195.159.176.226 (22 Jan 2017 08:08:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2017 08:08:15 +0000 (UTC) Cc: mailing list for ConTeXt users To: Hans Hagen Original-X-From: ntg-context-bounces@ntg.nl Sun Jan 22 09:08:06 2017 Return-path: Envelope-to: gctc-ntg-context-518@m.gmane.org Original-Received: from zapf.boekplan.nl ([5.39.185.232] helo=zapf.ntg.nl) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cVDC1-0002W0-CC for gctc-ntg-context-518@m.gmane.org; Sun, 22 Jan 2017 09:08:05 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id A110C12601E7; Sun, 22 Jan 2017 09:07:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at zapf.boekplan.nl Original-Received: from zapf.ntg.nl ([127.0.0.1]) by localhost (zapf.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfp8hG8oMcU3; Sun, 22 Jan 2017 09:07:39 +0100 (CET) Original-Received: from zapf.ntg.nl (localhost [IPv6:::1]) by zapf.ntg.nl (Postfix) with ESMTP id 8087E12601C4; Sun, 22 Jan 2017 09:07:39 +0100 (CET) Original-Received: from localhost (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id 9B5B01260208 for ; Sat, 21 Jan 2017 22:13:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at zapf.boekplan.nl Original-Received: from zapf.ntg.nl ([127.0.0.1]) by localhost (zapf.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjsmCp_jnHye for ; Sat, 21 Jan 2017 22:13:12 +0100 (CET) Original-Received: from mail-yb0-f170.google.com (mail-yb0-f170.google.com [209.85.213.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by zapf.ntg.nl (Postfix) with ESMTPS id 6AA811260207 for ; Sat, 21 Jan 2017 22:13:02 +0100 (CET) Original-Received: by mail-yb0-f170.google.com with SMTP id l23so77317777ybj.2 for ; Sat, 21 Jan 2017 13:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3e2hPmFVSl8/oMCO8LLiKMtjEHJWXVhTUh7f3yCEy2s=; b=bRfYUdzey8Rh6NUF50fSco7xUnuLPL6z6AkvDpthujjlNKK5M82voOdCR8leOqKUAi dHryGtOEVZ7eBMnLglH7qFKUKJIW1x5qLmF9gjNRFPSDeKZvU0K2xIFwsd51zAzMzEm+ vlG9sSLBMfaX0oN9WrMZMv0kGU6slIbDWM1t/SXPObkPZ7DOvZgPCw0DYYjHveVLPlU1 UlC+vrOETBG4/y3TI8jbI7m1T08WsMm/sU9H1+WBCWzV4VF2ZScerLh5i+ksqETdMG0f UvUzdvpGQLNzJ9yzRNAk1lPUG6//Fo+Chgz5/FWkNZKI3CVYzObRrkvN9vHV0fFlGFe5 MZug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3e2hPmFVSl8/oMCO8LLiKMtjEHJWXVhTUh7f3yCEy2s=; b=N1Exby++0L0+DF1P0UtfM2kTyYZEv+KZU+0d1HId9wpwam4jxSbONoPx5s5B+xd7/X 4dGJ97IIFzraRsj58vpD/zUFjm8z7SVu5GOUpHFoK1Sy3RMu1ZMJIndKlEQq+snh5X7G 3FC/+RfwXSrLyw8yS9gVME0KBNTriI7BDSu2Vw6HfzCQCBufOouN7C+2ufzo3WCWHo8N hjowbYQm5Vynwmk1Pqnn931evUEtLDGy1cfZpmr7KclDbjLbae+uoouIbe2RUKcTdBDe uRJ9sXgxAhHjyHMeWzdYd7AGBnDPvUnnhJyhmntEgXcDpk70fgU6BDWLoiviQG8EPI0V ttrg== X-Gm-Message-State: AIkVDXKk/wuCuEp5X6Tsb+tPDtCiuxsg5qGGwiPt+ccvq+4ASSXU7h1HSkgWr+QyDC5Y4he8oUquZarQ87oPQQ== X-Received: by 10.37.215.8 with SMTP id o8mr16436941ybg.158.1485033180968; Sat, 21 Jan 2017 13:13:00 -0800 (PST) Original-Received: by 10.37.162.65 with HTTP; Sat, 21 Jan 2017 13:13:00 -0800 (PST) In-Reply-To: <5ff6c190-3493-e46a-2fa9-909cb1abb3c8@wxs.nl> X-Mailman-Approved-At: Sun, 22 Jan 2017 09:07:38 +0100 X-BeenThere: ntg-context@ntg.nl X-Mailman-Version: 2.1.16 Precedence: list List-Id: mailing list for ConTeXt users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ntg-context-bounces@ntg.nl Original-Sender: "ntg-context" Xref: news.gmane.org gmane.comp.tex.context:97130 Archived-At: --===============6054716789549127667== Content-Type: multipart/alternative; boundary=94eb2c0799b63b3eea0546a13b5b --94eb2c0799b63b3eea0546a13b5b Content-Type: text/plain; charset=UTF-8 On Tue, Jan 17, 2017 at 11:35 AM, Hans Hagen wrote: > On 1/16/2017 8:31 PM, Sergey Slyusarev wrote: > >> the (subtle) difference between the two [*MPinclusions and >>> */MPinitializations/] is not a bug but a feature >>> >> >> If I understood correctly, *MPinitializations affects everything and >> can't be assigned to a specific instance (or can it?), >> in some cases (like mine) this difference is not so subtle. >> >> Look at the following example (not so minimal): >> >> \startMPinitializations >> >> picture p; >> >> p := image( >> >> draw fullsquare scaled 1cm; >> >> draw textext("1"); >> >> ); >> >> \stopMPinitializations >> >> \startMPinitializations >> >> picture s; >> >> s := image( >> >> draw (fullsquare rotated 45) scaled 1cm; >> >> draw textext("2"); >> >> ); >> >> \stopMPinitializations >> >> \defineMPinstance[foo][initializations=yes] >> >> \startMPcode{foo} >> >> picture q; >> >> q := image( >> >> draw fullcircle scaled 1cm; >> >> draw textext("3"); >> >> ); >> >> draw q; >> >> \stopMPcode >> >> \startMPcode{foo} >> >> draw p; >> >> draw q shifted (2cm, 0); >> >> draw s shifted (4cm, 0); >> >> \stopMPcode >> >> \defineMPinstance[bar][initializations=yes] >> >> \startMPcode{bar} >> >> picture r; >> >> r := image( >> >> draw fullcircle scaled 1cm; >> >> draw textext("4"); >> >> ); >> >> draw r; >> >> \stopMPcode >> >> \startMPcode{bar} >> >> draw p; >> >> draw r shifted (2cm, 0); >> >> draw s shifted (4cm, 0); >> >> \stopMPcode >> >> >> First, it shows why *MPinitializations can't replace *MPinclusions for >> me (it affects all instances), >> >> and second, it silently produces produces some really unexpected results: >> >> It looks like it should produce (by line) >> >> A circle with "3" inside (yes) >> >> A square with "1" inside (yes); A circle with "3" inside again (no, >> instead it produces circle with "2" inside); A rhombus with "2" inside >> (no, instead it produces a rhombus with "1") >> >> and so on. >> >> (tested on http://live.contextgarden.net/) >> >> In fact, I failed to declare picture variable inside with text inside >> one *MPcode environment and pass it to another safely >> >> (text either disappears or changes to other text, and this time ConTeXt >> returns no error), that surely is a bug? >> > > no, it's the way it works ... but keep in mind that textexts are something > bound to a specific code snippet so you can bets do something like this: > > \starttext > > \defineMPinstance[foo][definitions=yes] > \defineMPinstance[bar][definitions=yes] > > \startMPdefinitions{foo} > vardef p = > image( > draw fullsquare scaled 1cm; > draw textext("1"); > ) > enddef ; > \stopMPdefinitions > > \startMPdefinitions{bar} > vardef p = > image( > draw (fullsquare rotated 45) scaled 1cm; > draw textext("2"); > ) > enddef; > \stopMPdefinitions > > \startMPcode{foo} > draw p; > draw image( > draw fullcircle scaled 1cm; > draw textext("3"); > ); > draw p; > \stopMPcode > > \startMPcode{bar} > draw p; > draw image( > draw fullcircle scaled 1cm; > draw textext("4"); > ); > \stopMPcode > > \stoptext > > > > ----------------------------------------------------------------- > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands > tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl > ----------------------------------------------------------------- > Thank you, Hans! I thought of this solution too ( http://tex.stackexchange.com/ questions/347908/metapost-text-labels-inside-mpinclusions/348066#348066 ), but in my particular case it didn't work, because the code inside vardef is only executed when macro is called (while image(...) is processed immediately). It would help if the macro could be called within *MPdefinitions, like this: \starttext \startMPdefinitions picture tmp; vardef p = image( draw fullcircle scaled 5cm; draw textext("test"); ) enddef; tmp := image(draw p;); \stopMPdefinitions \startMPcode draw p; \stopMPcode \stoptext but that predictably generates the same error ("! Equation cannot be performed (color=vacuous)."). Anyway, I solved my problem somehow (by running the code inside *reusableMPgraphic and reusing it for the first time inside \setbox that is never shown https://github.com/jemmybutton/byrne-euclid/commit/8c05cc96405f0ee33e6901a7fa66b2dffcda45ad#diff-6a58985423a46a2bb439cfdf26904e5fL30 , at the cost of being unable to modify the image). Now I see that the fact that it's almost impossible to use images with text inside, outside of their environment of origin is not a bug, but a natural limitation of the system, and the first message should have been not about "bug", but more about something like "feature request". Sorry for being hasty. Sergey. --94eb2c0799b63b3eea0546a13b5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 17, 2017 at 11:35 AM, Hans Hagen <= pragma@wxs.nl> wrote:
On 1/16/20= 17 8:31 PM, Sergey Slyusarev wrote:
the (subtle) difference between the two [*MPinclusions and */MPinitializati= ons/] is not a bug but a feature

If I understood correctly, *MPinitializations affects everything and can= 9;t be assigned to a specific instance (or can it?),
in some cases (like mine) this difference is not so subtle.

Look at the following example (not so minimal):

\startMPinitializations

picture p;

p :=3D image(

draw fullsquare scaled 1cm;

draw textext("1");

);

\stopMPinitializations

\startMPinitializations

picture s;

s :=3D image(

draw (fullsquare rotated 45) scaled 1cm;

draw textext("2");

);

\stopMPinitializations

\defineMPinstance[foo][initializations=3Dyes]

\startMPcode{foo}

picture q;

q :=3D image(

draw fullcircle scaled 1cm;

draw textext("3");

);

draw q;

\stopMPcode

\startMPcode{foo}

draw p;

draw q shifted (2cm, 0);

draw s shifted (4cm, 0);

\stopMPcode

\defineMPinstance[bar][initializations=3Dyes]

\startMPcode{bar}

picture r;

r :=3D image(

draw fullcircle scaled 1cm;

draw textext("4");

);

draw r;

\stopMPcode

\startMPcode{bar}

draw p;

draw r shifted (2cm, 0);

draw s shifted (4cm, 0);

\stopMPcode


First, it shows why *MPinitializations can't replace *MPinclusions for<= br> me (it affects all instances),

and second, it silently produces produces some really unexpected results:
It looks like it should produce (by line)

A circle with "3" inside (yes)

A square with "1" inside (yes); A circle with "3" insid= e again (no,
instead it produces circle with "2" inside); A rhombus with "= ;2" inside
(no, instead it produces a rhombus with "1")

and so on.

(tested on http://live.contextgarden.net/)

In fact, I failed to declare picture variable inside with text inside
one *MPcode environment and pass it to another safely

(text either disappears or changes to other text, and this time ConTeXt
returns no error), that surely is a bug?

no, it's the way it works ... but keep in mind that textexts are someth= ing bound to a specific code snippet so you can bets do something like this= :

\starttext

\defineMPinstance[foo][definitions=3Dyes]
\defineMPinstance[bar][definitions=3Dyes]

\startMPdefinitions{foo}
=C2=A0 =C2=A0 vardef p =3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 image(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draw fullsquare scaled 1cm;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draw textext("1");
=C2=A0 =C2=A0 =C2=A0 =C2=A0 )
 =C2=A0 =C2=A0 enddef ;
\stopMPdefinitions

\startMPdefinitions{bar}
=C2=A0 =C2=A0 vardef p =3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 image(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draw (fullsquare rotated 45) scal= ed 1cm;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draw textext("2");
=C2=A0 =C2=A0 =C2=A0 =C2=A0 )
 =C2=A0 =C2=A0 enddef;
\stopMPdefinitions

\startMPcode{foo}
=C2=A0 =C2=A0 draw p;
=C2=A0 =C2=A0 draw image(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draw fullcircle scaled 1cm;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draw textext("3");
=C2=A0 =C2=A0 );
 =C2=A0 =C2=A0 draw p;
\stopMPcode

\startMPcode{bar}
=C2=A0 =C2=A0 draw p;
 =C2=A0 =C2=A0 draw image(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draw fullcircle scaled 1cm;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draw textext("4");
=C2=A0 =C2=A0 );
 \stopMPcode

\stoptext



-----------------------------------------------------------------=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 H= ans Hagen | PRAGMA ADE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ridderstraat 27 | 8061 GH = Hasselt | The Netherlands
=C2=A0 =C2=A0 =C2=A0 =C2=A0tel: 038 477 53 69 | www.pragma-ade.nl | www.p= ragma-pod.nl
-----------------------------------------------------------------=

Thank you, Hans!
I thought of thi= s solution too ( ht= tp://tex.stackexchange.com/questions/347908/metapost-text-labels-= inside-mpinclusions/348066#348066 ), but in my particular case it didn't work, because the code inside=20 vardef is only executed when macro is called (while image(...) is=20 processed immediately). It would help if the macro could be called=20 within *MPdefinitions, like this:

\starttext
\startMPdefinitions<= br>picture tmp;
vardef p =3D
image(
draw fullcircle scaled 5cm;draw textext("test");
)
enddef;
tmp :=3D image(draw p;)= ;
\stopMPdefinitions
\startMPcode
draw p;
\stopMPcode
\stopt= ext

but that predictably generates the same error ("= ! Equation cannot be performed (color=3Dvacuous).").

Anyw= ay, I solved my problem somehow (by running the code inside=20 *reusableMPgraphic and reusing it for the first time inside \setbox that is never shown https://github.com/jemmybutton/byrne-euclid/commit/8c05cc96405f0= ee33e6901a7fa66b2dffcda45ad#diff-6a58985423a46a2bb439cfdf26904e5fL30 , = at the cost of being unable to modify the image).
Now I see that the fact that it's almost impossible to use images with tex= t inside, outside of their environment of origin is not a bug, but a=20 natural limitation of the system, and the first message should have been no= t about "bug", but more about something like "feature reques= t". Sorry for being hasty.

Ser= gey.
--94eb2c0799b63b3eea0546a13b5b-- --===============6054716789549127667== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KSWYgeW91ciBxdWVzdGlvbiBpcyBvZiBpbnRlcmVz dCB0byBvdGhlcnMgYXMgd2VsbCwgcGxlYXNlIGFkZCBhbiBlbnRyeSB0byB0aGUgV2lraSEKCm1h aWxsaXN0IDogbnRnLWNvbnRleHRAbnRnLm5sIC8gaHR0cDovL3d3dy5udGcubmwvbWFpbG1hbi9s aXN0aW5mby9udGctY29udGV4dAp3ZWJwYWdlICA6IGh0dHA6Ly93d3cucHJhZ21hLWFkZS5ubCAv IGh0dHA6Ly9jb250ZXh0LmFhbmhldC5uZXQKYXJjaGl2ZSAgOiBodHRwczovL2JpdGJ1Y2tldC5v cmcvcGhnL2NvbnRleHQtbWlycm9yL2NvbW1pdHMvCndpa2kgICAgIDogaHR0cDovL2NvbnRleHRn YXJkZW4ubmV0Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f --===============6054716789549127667==--