23.10.2014 Views

mfpic-doc.pdf.

mfpic-doc.pdf.

mfpic-doc.pdf.

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

4.12 FOR ADVANCED USERS. 70<br />

... }. Tiling an open curve is technically an error, but the METAFONT code responds by drawing<br />

the path and not doing any tiling. The METAFONT code places shifted copies of the tile picture in a<br />

rectangular grid sufficient to cover the region, then clips it to the closed path before drawing it.<br />

Tiling large regions with complicated tiles can exceed the capacity of some versions of META-<br />

POST. There is less of a problem with METAFONT. This is not because METAFONT has greater<br />

capacity, but because of the natural difference between bitmaps and vector graphics.<br />

In METAPOST, the tiles are copied with whatever color they are given when they are defined.<br />

They can be multicolored.<br />

Before version 0.8, \tile was the only way to create a picture variable, and the only way to<br />

draw this picture was with the \tess command. Now we have the following command to place<br />

multiple copies of a picture:<br />

\putmfpimage{〈name〉}{〈list〉}<br />

This take the name of a picture variable and copies the picture at each location in the 〈list〉, which<br />

should be a comma-separated list of coordinate pairs in graph coordinates. The picture is copied so<br />

that its reference point is placed at each of the locations. The reference point of a picture created<br />

with \tile is its lower left corner.<br />

\mfpimage[〈refpt〉]{〈picname〉}<br />

〈MFPIC drawing commands〉<br />

\endmfpimage<br />

This is another way to create a picture variable. The drawing commands within the mfpimage<br />

environment contribute not to the current MFPIC picture, but rather to the picture variable named in<br />

〈picname〉. Otherwise, they operate exactly as they would outside this environment, using the same<br />

coordinate system and the same default values of all parameters, etc. (unlike the tile environment,<br />

which defines its own coordinate system). The picture is created with its reference point at the point<br />

〈refpt〉 given in the optional argument. The default is (0,0). For example:<br />

\mfpimage[(1,1)]{Jan}<br />

\fill\rect{(0,0),(1,1)}<br />

\fill\rect{(1,1),(2,2)}<br />

\rect{(0,0),(2,2)}<br />

\endmfpimage<br />

produces a simple 2-by-2 chessboard with its reference point at the center point (1,1). One can then<br />

write something like<br />

\putmfpimage{Jan}{(1,1),(3,1),(1,3),(3,3)}<br />

to get a 4-by-4 chessboard: the picture Jan copied with its center at each of the listed points.<br />

The behavior of \tlabel in an mfpimage environment depends on the setting. If mplabels is<br />

turned off, then labels are added by TEX and are not included as part of the named METAFONT or<br />

METAPOST picture variable. They are placed on the current picture as if the mfpimage environment<br />

were not there at all. If mplabels is turned on and overlaylabels is also turned on, or if the mfpimage<br />

environment is between \startbacktext and \stopbacktext, then the labels will be saved and<br />

placed when the <strong>mfpic</strong> environment ends and not added to the named picture variable. Thus, to<br />

include text labels in the named picture variable, you must have mplabels on, overlaylabels off, and<br />

mfpimage outside any \startbacktext/\stopbacktext.<br />

The picture created by \mfpimage is locally defined. That is, it becomes undefined at the end of<br />

the current <strong>mfpic</strong> environment. If one needs it to be global, one can use \globalsetmfvariable<br />

(see subsection 4.12.4) to copy it to another variable. For example. the command

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!