ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Aditya Mahajan <adityam@umich.edu>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: Labels in MetaPost (MetaObj)
Date: Fri, 21 Jan 2011 20:38:37 -0500 (EST)	[thread overview]
Message-ID: <alpine.LNX.2.01.1101211941070.8633@ybpnyubfg.ybpnyqbznva> (raw)
In-Reply-To: <4D3A126F.8030804@wxs.nl>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2649 bytes --]

On Sat, 22 Jan 2011, Hans Hagen wrote:

> On 20-1-2011 9:59, Taco Hoekwater wrote:
>> On 01/18/2011 01:17 PM, Stefan Müller wrote:
>>> Hi list,
>>> 
>>> I'm having some trouble with MetaPost in general and MetaObj in
>>> particular.
>> 
>> The core problem is that context mkiv loads the metapost code twice
>> when you are typesetting labels, and that causes trouble for metaobj
>> which does not expect that. Sorry, I do not know of any solution.
>> Maybe Hans does?
>
> not immediately

A suggestion: Currently, ConTeXt does not clear the state 
of mplib at the end of each graphic. For example

     \starttext
     \startMPcode
       path p;
       p := fullcircle scaled 4cm ;
     \stopMPcode

     \startMPcode
       draw p ;
     \stopMPcode
     \stoptext

draws a circle. I am not convinced that this is useful. Resetting the state of
mplib after each graphic might be better. Then, after the first run, you could
just set the value of mptopdf.texts[..], reset the state of mplib, and then draw
the graphic in the second run.

This approach will have less surprises. For example, in simpleslides module, we
provide a mechanism for highlighting a part of a picture using arrows. These
arrows are thick (typically 5bp). In order to scale the arrows correctly, we
set:

   autoarrows := true ;

However, in the current implementation, this effect is global. It took a while
to realize that this messed up all the figures with arrows that I was drawing in
a presentation (where autoarrows := false) is better.

Not resetting the mplib state also has advantages. For example, it allows an
easy way to do something on the second path (trivial example, but there are
cases when something like this makes the code much shorter):

     \startMPinclusions[+]
       newboolean flag ;
       flag := false ;
     \stopMPinclusions

     \starttext
     \startMPpage
       if flag :
         fill boundary withcolor 0.5[blue,white] ;
       else :
         path boundary ;
       fi ;

       path A, B;

       A := fullsquare scaled 3cm ;
       B := fullsquare scaled 3cm shifted (5cm,0) ;

       fill A withcolor white ;
       fill B withcolor white ;

       draw A ; draw btex A etex ;
       draw B ; draw btex B etex shifted (5cm,0) ;

       boundary := (boundingbox currentpicture) enlarged 3mm ;

       flag := true ;

     \stopMPpage
     \stoptext

So, perhaps, we can have a `reset` key to \defineMPinstance, and let the user
choose whether to reset after each graphic or not. If `reset=yes` is chosen,
then such errors would not occur.

Aditya

[-- Attachment #2: Type: text/plain, Size: 486 bytes --]

___________________________________________________________________________________
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

  reply	other threads:[~2011-01-22  1:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-18 12:17 Stefan Müller
2011-01-20  8:59 ` Taco Hoekwater
2011-01-21 23:10   ` Hans Hagen
2011-01-22  1:38     ` Aditya Mahajan [this message]
2011-01-22 13:25       ` Stefan Müller
2011-01-22 16:30         ` Aditya Mahajan
2011-01-23 11:40           ` Stefan Müller
2011-01-23 12:25             ` Stefan Müller
2011-01-23 17:22               ` Aditya Mahajan
2011-01-23 21:14                 ` Stefan Müller
2011-01-24 15:34                   ` Stefan Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.01.1101211941070.8633@ybpnyubfg.ybpnyqbznva \
    --to=adityam@umich.edu \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).