Re: [NTG-context] A better \definesymbol sought

2017-01-22 Thread Alan Braslau
On Sun, 22 Jan 2017 22:39:53 -0500
Rik Kabel  wrote:

> So, how can I make the inner glyph (‘?’ in the example below)
> transparent, so that the background shows through along with anything
> else that lives on a lower layer? I’ve seen a method for constructed
> shapes, but nothing that I can apply to text glyphs. Undraw doesn’t
> do it.

Undraw is simply draw using the background color.

Transparency is a MetaFun extension to MetaPost (so part of ConTeXt).

draw q withtransparency (1,0.5) ; % (method,transparency)

Alan
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] A better \definesymbol sought

2017-01-22 Thread Rik Kabel

On 2017-01-20 23:54, Alan Braslau wrote:

On Fri, 20 Jan 2017 22:33:40 -0500
Rik Kabel  wrote:


Can anyone suggest a better way to compose such symbols than using
the raw TeX commands used here? Is there a more ConTeXt-ish way to do
this? Is it possible to get options to center the glyphs from which
the symbol is assembled (separate horizontal and vertical, with the
ability to offset them)?

Is there a ConTeXt way other than \definesymbol to create such
combined symbols?

MetaPost (with textext())?


Thank you for that, Alan. I hadn’t ever used MetaPost before, thinking 
it was too complex for my needs. Now I see it may be quite useful.


So, how can I make the inner glyph (‘?’ in the example below) 
transparent, so that the background shows through along with anything 
else that lives on a lower layer? I’ve seen a method for constructed 
shapes, but nothing that I can apply to text glyphs. Undraw doesn’t do it.


  \setupbackgrounds
   [page]
   [background=color,backgroundcolor=yellow]
 \definefont
   [DVSrB]
   [file:DejaVuSerif-Bold.ttf]
 \startuseMPgraphic{HeartTest}
   picture h;
   h := "♥" infont "\truefontname{DejaVuSerif-Bold.ttf}" scaled 20;
   picture q;
   q := textext("{\DVSrB ?}") scaled 10; % just a different way
   q := q shifted - (xpart center q, 12pt) ;
   draw h withcolor blue;
   undraw q;   % this doesn't do it
 \stopuseMPgraphic
 \starttext
   \useMPgraphic{HeartTest}
 \stoptext

--
Rik

___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Custom pretty printer pass option to buff-imp-.lua

2017-01-22 Thread Lorenz
It looks like the solution is to add another visualizers.register() to
the .lua file.  

visualizers.register("custom", { parser = parser, handler = handler,
grammar = grammar } )
visualizers.register("customb", { parser = parser2, handler =
handler2, grammar = grammar2 } )

Then in .mkiv:

\definetyping
[CUSTOM]
[\c!option=custom]

\definetyping
[CUSTOMB]
[\c!option=customb]


I'll just need to work out how to define only the changes I want to make
to handler2, grammar2 without copy/paste from handler, grammar.  I want
to share most of the options with the original and override select
options.


On Sun, Jan 22, 2017, at 02:35 PM, Lorenz wrote:
> I'm customizing a pretty printer and referencing the buff-imp-lua.lua
> and buff-imp-lua.mkiv files.  
> 
> I'd like to add a conditional to the .lua file say buff-imp-custom.lua. 
> What is a good way to pass an option from my .tex file to conditionally
> format with the pretty printer?   I'd like to use the same
> buff-imp-custom.lua and .mkiv pairs of files instead of creating
> multiple files.
> 
> The .mkiv file defines e.g.:
> 
> \definetyping
> [CUSTOM1]
> [\c!option=custom]
> 
> I'd like to add say CUSTOM2 but pass an option that would be visible to
> the same buff-imp-custom.lua file.  Perhaps something like this?:
> 
> \definetyping
> [CUSTOM2]
> [\c!option=custom,]
> 
> 
> Thanks 
> 
> --
> Lorenz
> ___
> If your question is of interest to others as well, please add an entry to
> the Wiki!
> 
> maillist : ntg-context@ntg.nl /
> http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
> ___
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

[NTG-context] Custom pretty printer pass option to buff-imp-.lua

2017-01-22 Thread Lorenz
I'm customizing a pretty printer and referencing the buff-imp-lua.lua
and buff-imp-lua.mkiv files.  

I'd like to add a conditional to the .lua file say buff-imp-custom.lua. 
What is a good way to pass an option from my .tex file to conditionally
format with the pretty printer?   I'd like to use the same
buff-imp-custom.lua and .mkiv pairs of files instead of creating
multiple files.

The .mkiv file defines e.g.:

\definetyping
[CUSTOM1]
[\c!option=custom]

I'd like to add say CUSTOM2 but pass an option that would be visible to
the same buff-imp-custom.lua file.  Perhaps something like this?:

\definetyping
[CUSTOM2]
[\c!option=custom,]


Thanks 

--
Lorenz
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Bug: \textext inside \*MPinclusions causes error

2017-01-22 Thread Hans Hagen

On 1/21/2017 10:13 PM, Sergey Slyusarev wrote:
>
> see below

It's a single tex run so you can do:

\starttext

\newbox\MyMpBox \setbox\MyMpBox\hbox{foo}

\startMPcode
draw textext("\copy\MyMpBox") ;
\stopMPcode

\startMPcode
draw textext("\copy\MyMpBox") rotated 45;
\stopMPcode

\stoptext


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 

Re: [NTG-context] Bug: \textext inside \*MPinclusions causes error

2017-01-22 Thread Sergey Slyusarev
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.