Hi,
I'm trying to fix the end-user problem I'm having (quoted below), and
think I found the source of the problem.
Around line 121 in Format.cpp:
string Formats::getFormatFromFile(FileName const & filename) const
{
<snip>
string const format = filename.guessFormatFromContents();
if (!format.empty())
return format;
// try to find a format from the file extension.
string const ext = getExtension(filename.absFilename());
<snip>
}
So it only looks at file extension in the case where
guessFormatFromContents can't guess - that seems wrong. It should get
the format from looking up the extension (same list of formats as the
Formats editor in Preferences), and if that fails (or there is no
extension) _then_ it should try to guess based on content. Unless
there is some complexity that hasn't occurred to me, it seems flipping
the order of these two tests in Formats::getFormatFromFile would
result in more correct (not to mention more configurable) behavior.
Anyone have any comments? I am happy to submit a patch against svn if
there are no objections to this idea.
Thanks,
Hugo Vincent
On 4/11/2009, at 12:07 AM, Hugo Vincent wrote:
Hi,
I'm trying to set up some custom file converters (which take
psfrag'd EPS files from matlab, do some "stuff" to the annotations
then render them to a PDF), and am distinguishing between what
"stuff" gets done by file extension. That is, for operation A, I
might call the file someplot.epstypeA, and set up a file converter
in LyX to call my script (which I've tested and it works). But for
some reason, LyX seems to ignore my file extension and just call the
plain EPS converter because it somehow knows (from MIME type?) that
the file is still just an EPS file. Is it possible to make LyX
prioritize user-specified converters over built-in ones?
Thanks,
Hugo
