Tuesday, March 25, 2003 Hans Hagen wrote: HH> At 10:07 PM 3/24/2003 -0500, Gary Pajer wrote:

...

I've tried to resist, but I have to ask. Why not write a simple batch file that runs MetaPost *and* changes the extension? That's what I do. ... Are you processing several MP scripts in one file ??

HH> Remembering that i did look into it long ago, i took a look in the core-fig HH> file; now, if you really want this kind of support, open core-fig.tex and HH> search for: HH> % new, test first HH> uncomment the doifnumberelse lines and you'll have the support needed (a HH> new format needs to be generated) I had thought of doing that (I had spotted the lines while trying to debug the problem), but what I think is important is that graphics inclusion should be, within limits, independent from extension. For example, while .<num> are usually MP output, I could have other formats (embeddable by PDF) using those extensions. As long as I can specify [type=...] or [method=...], the extension should be left whatever it is. The problem arises because when the name of the included graphic is the same as the \jobname, extension is discarded. To be precise, two things are done: some extensions are discarded from the extensions searched, and then the extension of the file is wiped. While the first action is very wise (prevents output/input clash, so indeed tex, xml, pdf and dvi should be not searched in such a case), the second is not a good idea: after the suppression of the extensions, the inclusion should continue normally: we're safe from clash because the "wrong" extensions will not be searched. Can *this* be fixed? -- Giuseppe "Oblomov" Bilotta