Angus Leeming wrote: > Georg, I don't know where you find the energy to resolve these, truly > tedious, bugs. Well done!
Thanks. It is not as difficult as it looks like: More than once I discovered a new bug when I tried to fix another one. > Incidentally, can you see a way to enable this level of support for > compressed eps files in the external inset? I've been mulling it over > for ages and haven't got anywhere. I see the following cases: Input conversion needed Output 1 uncompressed no uncompressed 2 uncompressed no compressed 3 uncompressed yes uncompressed 4 uncompressed yes compressed 5 compressed no uncompressed 6 compressed no compressed 7 compressed yes uncompressed 8 compressed yes compressed Of course 1 and 3 work already. 5 and 7 should be no problem to implement: uncompress the file if it is compressed and do everything (filename substitution and file conversion) on the uncompressed file. I believe that this is possible without the invention of new variables or changing the template syntax otherwise, only the semantics of the filename parameter is changed. Maybe the FileFilter pattern should be extended by the compressed file suffixes. I don't know if 2 and 4 are desired. If yes, we certainly need a flag "compress the output", but if we have this flag, the implementation should be easy. In this case (and also cases 6 and 8) we might need a new variable $$ZipExtension that contains the extension of compressed files. This variable would be empty in the cases 1, 3, 5 and 7. 6 is the case that corresponds to the graphics inset "nounzip" flag and can be handled if we inherit this flag. 8 can be handled by a combination of 7 and 4: first uncompress, then convert, then compress. It would also need the "compress the output" flag. Summary: I think that it is possible, but problems will probably only appear if somebody starts to implement it. Georg
