Re: Re[3]: Using MetaPost graphics in ConTeXt

Re: Re[3]: Using MetaPost graphics in ConTeXt

[Hans Hagen]

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 ??


Remembering that i did look into it long ago, i took a look in the core-fig 
file; now, if you really want this kind of support, open core-fig.tex and 
search for:

   % new, test first

uncomment the doifnumberelse lines and you'll have the support needed (a 
new format needs to be generated)

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
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------

Re[5]: Using MetaPost graphics in ConTeXt

[Giuseppe Bilotta]

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

Re[3]: Using MetaPost graphics in ConTeXt

[Giuseppe Bilotta]

Tuesday, March 25, 2003 Hans Hagen wrote:

HH> At 11:38 AM 3/25/2003 +0100, you wrote:

>>The third point is too severe in its behaviour: it's a good thing that
>>circular
>>loading is prevented, but this shouldn't prevent inclusion of
>>other files with different extensions! After the removal of the
>>\jobsuffix extension, inclusion should go on normally!

HH> it will, fo rthose sufixes that are recognized as being supported by the
HH> backend; numbers are special case in the sense that they don't relate to a
HH> file format; if you uncomment the lines i mentioned you get them supported

The problem is not the numbers as such, it's a more general point;
especially then type= or method= are specified, extension should
be irrelevant as long as it doesn't cause name clash. On a very
general basis, I would say that the best approach would be:

Step 1: check for name clashes:
 * if name = \jobname:
   (a) if extension = \jobsuffix or output suffix (dvi, pdf), quit
   parsing
   (b) if no extension, remove jobsuffix and output suffix from
   list of searched extensions.

Step 2: if extension is specified, and no method is specified,
set method to the one associated with this extension, if there is
one.

Step 3: check if file exists;
 * if we have a full name, try to open the specified
 name.extension, with the specified method
 * if the file is not found, and no extension was specified, look
 for all the known extensions (except the ones forbidden by Step
 1, point b); if a method/type is specified and it has a default extension,
 start looking from that extension

Or something like this ...

-- 
Giuseppe "Oblomov" Bilotta

Re: Re[3]: Using MetaPost graphics in ConTeXt

[Gary Pajer]

> Monday, March 24, 2003 Hans Hagen wrote:
> >>Doesn't work either. Fails with the same errors. Again, it works
> >>correctly by changing the extension.
> >>
> >>A possible reason for the error is that the name of the tex file
> >>is the same as the name of the figure file (test), because ConTeXt
> >>*does* check for this, and this is where it chooses not to handle
> >>the picture. Given that the same file works if the extension is
> >>mps, I can't understand why it refuses to do the job when the
> >>extension is different, and still different from .tex and .pdf
>
> HH> or xml or the yet to be invented superior coding standard 'number one'
with
> HH> suffix 1
>
> Ok, but in the mean time how is one supposed to include MetaPost
> output without having to rename the files?

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 ??

-Gary

Re[3]: Using MetaPost graphics in ConTeXt

[Giuseppe Bilotta]

Monday, March 24, 2003 Hans Hagen wrote:
>>Doesn't work either. Fails with the same errors. Again, it works
>>correctly by changing the extension.
>>
>>A possible reason for the error is that the name of the tex file
>>is the same as the name of the figure file (test), because ConTeXt
>>*does* check for this, and this is where it chooses not to handle
>>the picture. Given that the same file works if the extension is
>>mps, I can't understand why it refuses to do the job when the
>>extension is different, and still different from .tex and .pdf

HH> or xml or the yet to be invented superior coding standard 'number one' with
HH> suffix 1

Ok, but in the mean time how is one supposed to include MetaPost
output without having to rename the files?

-- 
Giuseppe "Oblomov" Bilotta