General inquiries

General inquiries

[David Arnold]

Hans et al,

1. Can you explain the difference between the switches --nomp and
--nomprun? What's the difference?

2. Let's say you are working on a doc. The doc has embedded MP graphics.
You get a good compile, the images are generated, and you go back to typing
the source. You work a bit, entering narrative, but no new MP graphics. How
should the next compile be run?

 texexec --pdf --nomp filename

or

 texexec --pdf --nomprun filename

Or perhaps some other option?

Also, once you get a good compile, how does Context know about the graphics
when you do a texexec --nomp or texexec --nomprun? Is the answer you will
provide to this question valid whether or not \recycleMPslotstrue is set?
Is it true that once the embedded graphics are crafted at runtime, future
compiles need not regenerate these graphics because they are available for
future compiles?

3. The way I usually work, I will type several paragraphs of code, then
compile to see how I am doing. I am reticent to type pages and pages
without checking, for fear that I will create such a morass of errors that
I will never figure my way out of the mess. So, my editing cycle is usually
type a bit a code, compile and check, fix errors, type a little code,
compile and check, fix errors, .... What's the best way to compile in this
situation?

4. What can be frustrating is to watch Context compiling a document for a
significant amount of time, only to finally inform me after a minute or so
that I have mispelled some command, forgotten a $ sign, or some such error
that is typical of the normal tex editing cycle. Is there some way to
bypass all the preliminary stuff and just do a quick check for this sort of
error? Any advice here?

5. I will usually compile metapost graphics with mpost, then view in
Gsview. It is so much faster this way. Once I have my Metapost graphic(s)
just right, then I will embed it (them) into my Context document. Is there
a similar method that will compete with this development speed that you
might suggest?

6. Which of the following will give faster processing?

 \startbuffer[name]
   MPcode
 \stopbuffer

 \placefigure
 [here][fig1]
 {caption}
 {\processMPbuffer[name]}

or

 \startreusableMPgraphic{name}
   MPcode
 \stopreusableMPgraphic

 \placefigure
 [here][fig1]
 {caption}
 {\reuseMPgraphic{name}}

Or do you suggest a better way for faster, more efficient processing? Which
method leaves the fewest auxiliary files hanging around after the compile?

Thanks.

Re: General inquiries

[Hans Hagen]

At 09:41 PM 1/19/01 -0800, David Arnold wrote:
>Hans et al,
>
>1. Can you explain the difference between the switches --nomp and
>--nomprun? What's the difference?

--nomp can be uses in the [currently rare] case that tex calls mp calls tex
calls mp calls tex calls mp calls tex ... freezes windows

>2. Let's say you are working on a doc. The doc has embedded MP graphics.
>You get a good compile, the images are generated, and you go back to typing
>the source. You work a bit, entering narrative, but no new MP graphics. How
>should the next compile be run?
>
> texexec --pdf --nomp filename
>
>or
>
> texexec --pdf --nomprun filename

If you consistently use --nomprun every next run will have the right
graphics. This is a good method when you are sure that the graphics don't
interfere [use numeric abc later as pair and vise versa] and graphic
dimensions are based on cq. determine layout properties in which case they
can [temporarily] get out of sync. 

>Or perhaps some other option?
>
>Also, once you get a good compile, how does Context know about the graphics
>when you do a texexec --nomp or texexec --nomprun? Is the answer you will
>provide to this question valid whether or not \recycleMPslotstrue is set?
>Is it true that once the embedded graphics are crafted at runtime, future
>compiles need not regenerate these graphics because they are available for
>future compiles?

When the graphic does not change [reusable or unique graphics] they will be
reused anyway. 

The \recycleMPslotstrue will become default when i can conclude that
everything works as expected.

I am thinking of a checksum calculation to determine unchanged graphics,
btw, this is already used in mpo generation [outline fonts], btu this is
not that safe. In many cases --nomprun is your friend, since the mprun
itself is always quite fast.  

>3. The way I usually work, I will type several paragraphs of code, then
>compile to see how I am doing. I am reticent to type pages and pages
>without checking, for fear that I will create such a morass of errors that
>I will never figure my way out of the mess. So, my editing cycle is usually
>type a bit a code, compile and check, fix errors, type a little code,
>compile and check, fix errors, .... What's the best way to compile in this
>situation?

(1) here we select and run that part [all defs go before the
\starttext|...] and are also copied to the temp file
(2) use a small temp file [which is what i often do] and copy the text to
the main file when ok

>4. What can be frustrating is to watch Context compiling a document for a
>significant amount of time, only to finally inform me after a minute or so
>that I have mispelled some command, forgotten a $ sign, or some such error
>that is typical of the normal tex editing cycle. Is there some way to
>bypass all the preliminary stuff and just do a quick check for this sort of
>error? Any advice here?

Isn't your editor capable of testing on missing $'s? Any odd number of them
is wrong. 

>5. I will usually compile metapost graphics with mpost, then view in
>Gsview. It is so much faster this way. Once I have my Metapost graphic(s)
>just right, then I will embed it (them) into my Context document. Is there
>a similar method that will compete with this development speed that you
>might suggest?

no, sounds ok. 

>6. Which of the following will give faster processing?
>
> \startbuffer[name]
>   MPcode
> \stopbuffer
>
> \placefigure
> [here][fig1]
> {caption}
> {\processMPbuffer[name]}
>
>or
> 
> \startreusableMPgraphic{name}
>   MPcode
> \stopreusableMPgraphic
>
> \placefigure
> [here][fig1]
> {caption}
> {\reuseMPgraphic{name}}

the same, unless you use {name} a second time, in which case the second
method is faster

>Or do you suggest a better way for faster, more efficient processing? Which
>method leaves the fewest auxiliary files hanging around after the compile?

You can just make stand alone graphics, or even: 

(1) put your graphics in david.mp
(2) "mpost david" or "texexec --mprun david"
(3) "texexec --pdf --fig=c david.*" 
(4) "move texexec.pdf david.pdf" 
(5) use \externalfigure[david.pdf][page=23] to fetch the figure
"beginfig(23) ... endfig"

So, lots of ways to go. 

Hans
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------