Re: Possible bug with boxit

Thank you for your response. It sounds like something that might not be easy to fix. Perhaps it would be a good idea to revise the manual so that it notes the limitations of the "boxes" macros.

Some months ago I had a different problem: I tried to use one or more objects returned by boxit in a loop, but it didn't work and I got another cryptic error message. I assigned the values I needed to another variable and the loop worked. I must have this code somewhere but I don't remember off-hand where it could be. I'll try to find it.

Incidentally, I noticed something else in the manual (mpman): Page 43: "There is also

an unfilldraw statement just in case someone finds a use for it." Actually, this command is useful, if for instance, one draws a cyclical path with a particular pen and then wants to unfill it later, or conditionally, or on a different picture, or whatever. This isn't even an obscure usage.

Gesendet: Montag, 28. Februar 2022 um 17:45 Uhr

Von: "Daniel H. Luecking" <[email protected]>

An: "Laurence Finston" <[email protected]>, "[email protected]" <[email protected]>

Betreff: Re: [metapost] Possible bug with boxit

The file boxes.mp adds the command

save pic_;

to extra_beginfig. This seems likely to be the problem: drawunboxed ultimately makes use of pic_.

Also, extra_endfig has clearboxes added, which may also cause problems (although I don't really understand all that it does).

Cheers,

Daniel H. Luecking [[email protected]]

Department of Mathematical Sciences

1 University of Arkansas

Fayetteville, AR, USA 72701-1201

----------

From: metapost <[email protected]> on behalf of Laurence Finston <[email protected]>

Sent: Tuesday, February 22, 2022 4:41 PM

To: Metapost List <[email protected]>

Subject: [metapost] Possible bug with boxit

In the attached MP file, I use macros from boxes.mp. It doesn't fail to call boxit outside of a figure, but it doesn't produce the expected result (at least, the one I expected): If I call it outside of a figure but not within the figure, I get this error when I call drawunboxed:

>> sproc_.C

! Not a string.

<to be read again>

(

<for(C)> scantokens.sproc_(SUFFIX0)(

(SUFFIX0)); ENDFOR

fixsize->...$=(TEXT2):scantokens.sproc_$($);endfor

.endgroup

drawunboxed->fixsize((TEXT0))

;fixpos((TEXT0));forsuffixes.s=(TEXT0):draw.pic...

l.290 drawunboxed(C)

;

?

If I call it outside the figure and then inside it, I get this error:

! Redundant equation.

<to be read again>

;

boxit->...FIX2)sw)=ypart((SUFFIX2)se-(SUFFIX2)sw);

0=xpart((SUFFIX2)ne-(SUFFI...

l.273 boxit.C(V67)

; %% boxit must be called here in order for drawunboxed...

?

If I call it in figure 0 and don't call it in the following figure (100), I get the following error when I call bpath in fig. 100:

>> sproc_.C

! Not a string.

<to be read again>

(

<for(C)> scantokens.sproc_(SUFFIX0)(

(SUFFIX0)); ENDFOR

fixsize->...$=(TEXT2):scantokens.sproc_$($);endfor

.endgroup

bpath->begingroup.fixsize((SUFFIX2))

;fixpos((SUFFIX2));scantokens.pproc_(SUF...

<to be read again>

;

l.326 undraw bpath(C);

?

If I call boxit in both figures and not outside them, it works and the following two files are output:

ttemp000.eps .. ttemp100.eps

I didn't find any indication in mpboxes.pdf that the variables created by boxit would be local to an enclosing figure and I wouldn't have expected this behavior.

Is this a bug?

Thanks,

Laurence

--
http://tug.org/metapost/