Re: [NTG-context] Using MetaPost graphics in ConTeXt
At 08:16 PM 3/24/2003 +0100, you wrote:
The macro \calculateexternalfigure seems to set the extension to empty if the figure file name is the same as the jobname:
% redo message, only filename \doifparentfileelse\@@effilename {\@EA\removefromcommalist\@EA{\jobsuffix}\figuretypes \let\@@efextension\empty \showmessage\m!figures9\@@effilename \donefalse} \donothing
(core-fig.tex)
Therefore it does not search for your nonstandard extension.
the search for graphics is kind of fuzzy and dates from the time that we were still using dvi (different backends) - without suffix: try the best quality (depends on spec driver support) - with suffix: try that first, else locate alternative - same as parent file: try to avoid circular loading (keep in mind that tex code can be a graphic, i.e. buffers can be scaled) - all these are combined with a search over several paths, utilityfile, etc also, most of this is overloaded when using figure databases -) 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 -------------------------------------------------------------------------
Tuesday, March 25, 2003 Hans Hagen wrote: HH> the search for graphics is kind of fuzzy and dates from the time that we HH> were still using dvi (different backends) HH> - without suffix: try the best quality (depends on spec driver support) HH> - with suffix: try that first, else locate alternative HH> - same as parent file: try to avoid circular loading (keep in mind that tex HH> code can be a graphic, i.e. buffers can be scaled) 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! -- Giuseppe "Oblomov" Bilotta
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!
it will, fo rthose sufixes that are recognized as being supported by the backend; numbers are special case in the sense that they don't relate to a file format; if you uncomment the lines i mentioned you get them supported 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 -------------------------------------------------------------------------
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
participants (2)
-
Giuseppe Bilotta -
Hans Hagen