Georg Baum wrote: >>> So, if you open >>> /path/file.lyx and File>Export>Format, you will get a directory >>> /path/file.format.conversion/ in which all the files generated by the >>> converter will be found (e.g. the mess that htlatex generates ends up >>> in/path/file.html.conversion/). >>> > A flag for the name of that directory does already exist: resultdir. Please > use that instead of /path/file.html.conversion/. > I could be wrong, but this seems to do something else. /path/file.html.conversion/ is where the files end up if you're exporting, and the copying happens in Exporter.cpp. The resultdir flag operates in Converter.cpp and seems (though it's hard to tell, since it's not actually used in any of our converters) to inform us where the external converter will have put its output, and then things get moved in Converter.cpp, and then they get moved again in Exporter.cpp, if we're exporting. I also don't think we want to require resultdir to be set whenever usetempdir is. It may well be though (I haven't tried) that setting resultdir with usetempdir is possible and works as one would hope. >>> As a result, the originaldir flag does not need to be used by any of our >>> converters, and it may be redundant, though there's no harm leaving it, >>> so far as I can see. >>> > IMHO it should be removed. Have done. When I looked more closely, it caused massive problems: The existing code copies all HTML files found in the original directory to the temporary directory, whether they were created by the converter or not! It's amazing there's no bug report for that. >>> As you will note, doing this involved adding a new signature to the >>> Converters::convert() routine. I have not changed any of the other calls >>> to this: these are in Importer.cpp, insets/InsetGraphics.cpp, and >>> insets/ExternalSupport.cpp. At least some of these will need modifying >>> before the patch is applied, probably all of them, as I suppose >>> usetempdir could be set for importers and graphics converters and such. >>> > IMHO there should only be one interface, and I don't like the new one: If > the resulting file name is determined by the converter in some cases, then > why not do this always? AFAIK the callers of the converter determine the > result from the old name and the format extension anyway, so this should > be easy to change. > Here's an idea: Instead of Converter::convert() returning a boolean, have it return a the location of the converted file as a FileName. It can return an empty one (checkable with FileName::empty()) on error. I'll still need the used_temp_dir boolean as a flag, though, ... > Then there is some error checking missing: If the caller can't deal with a > converted directory (e.g. for preview) then it should check that the > result is indeed a file and act appropriately if that is not the case. > as I do NOT want to return a directory. The HTML converter, for example, dumps about a billion files but there is going to be one that the viewer wants, and it's that FileName I want to return, since there's no general way in which to recover it. The temporary directory, on the other hand, can be recovered as the path portion of the file name. Then again, I suppose I could return a std::pair<FileName, bool> or a std::pair<FileName, FileName>, with the latter being the temporary directory if one was created, rather than have a bool & as an argument. Advice welcome. My intuitions aren't always great here. (I tend to think Perl. Just make it work.) > BTW there is another problem in this area that I solved in my playground > branch: Some converters don't accept a commandline argument to set the > resulting file name, but determine it using their own rules. They only > work if these rules match the naming given by LyX, but will fail if a user > changes e.g. the extension of a format. I solved this by a new resultfile > flag. > I think you might have committed this. I see the resultfile flag in the exiting code and was wondering exactly what it did. Again, there's no converter that ships with LyX (i.e., that is configured by configure.py) that sets this.
Richard -- ================================================================== Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ ================================================================== Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
