Jens Noeckel wrote: > The simple answer is: I'd like to see backwards compatibility > restored, because if you want to take lyx seriously as a command-line > tool AS WELL AS a GUI application, you have to expect that users will > find unforeseen uses for lyx. Just as the makers of ImageMagick had > to expect that "convert -depth 8" will be made an integral part of > LyX, the makers of lyx should then expect that "lyx --export" will be > relied on in some new application. Since "lyx --export" used to leave > graphics untouched in earlier versions, it should stay that way. What > would LyX developers say if "convert -depth 8" suddenly started to > add a legend to every figure it converts... (just to make a point)?
I am very concerned about compatibility (look at the lyx2lyx stuff I implemented), but that cannot mean that we are not allowed to change anything. As I already explained to Enrico I think that "lyx -e latex mydoc.lyx" should produce something that works with latex. After all, it is not "lyx -e incomplete-latex mydoc.lyx". What was probably not a good idea: Making overwriting files the default, but it was only a logical extension from the behaviour WRT included child documents. I think we should not overwrite anything by default, and add a -f commandline switch that forces to overwrite files. > There are many applications for a bare LaTeX export. For one of my > lectures several years ago, I had made a script that exports a LyX > document as as PHP script so that it not only shows what I typed but > also includes some dynamic information. In that case, the included > graphics were placeholders for the points where dynamic information > is inserted in the PHP script. So I have no need for the graphics > from the LyX document to be touched during export. In this case you should have used the External Material inset with a specialized template. With the External Material inset you have full power over what gets exported and what not. We could even distribute such a template with LyX if it is of general use. > That's perhaps one of the more esoteric applications. But if I look > at the LyX export menu, there is a Custom Option, which obviously > means that you encourage the user's creativity in this respect. I never understood what this option is for. Why is it not possible to simply define a converter latex -> myfancycustomformat or lyx -> myfancycustomformat? What does work with Export->Custom that would not work with such a converter? > In this case, I export the LyX file to a temporary tex file, make > various replacements in the tex file (using tex4ht's HCode to insert > custom CSS layouts in inline equations that have simple two- > dimensional structures like vectors or overbars, thereby reducing the > number of GIFs needed for inline formulas). Now during this whole > process, there is NEVER any need for EPS graphics version of my LyX > document to be created. All I need is the original graphics, the > plain tex file, and then feed a modified tex file (with the ORIGINAL > pictures) to htlatex (tex4ht) which then converts graphics to PNG or > JPG format. That makes sense, but this is really expert usage. > This is just one example that I actually use a lot. I'm sure that > many others can be contrived... I am not so sure, but nevertheless: If we are going to add such an incomplete latex export that you want: What should be omitted? - Only files included by the graphics inset? That would not make much sense, since e.g. the xfig external template produces also graphics. - Omit files included by the external inset and the graphics inset? Does not make much sense either, since the external inset can also include something in .tex format. - Omit all included files (included by graphics, external and include inset)? That would be consistent, but probably not what you want. Georg
