Georg Baum wrote:
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.
I always saw the external inset as a way of supporting odd
kinds of figures, not a way to get an odd export of normal
graphics.
After all, one kan imagine that the document is supposed to both
print the normal way, and be used in Jens special way as well.
So some way of printing / making standard pdf must exist,
and therefore it makes sense to always use a graphics
inset for supported kinds of graphichs. And instead have a
special export.
I definitely see how a "latex only" export could be useful for
other purposes:
Someone developing a new conversion routine for some new
output format would find it a useful starting point. New
output format might not need .eps .
This covers not only Jens' case, but all sorts of new or obscure
formats. The implementation seems simple - output full filenames
and just skip conversions. It makes experimenting with
output conversion easier, and might even get us some more
outputs with time.
Helge Hafting
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.
Definitely omit the graphichs inset, and don't omit the include inset.
The external inset already support doing different conversions
for latex and pdflatex. These are specified for each type of
external inset. I think the action for "latex only" should be
a third category of per-inset export actions.
A picture-like inset that somehow produce .eps or .pdf
today, could take a do-nothing approach. An external inset
that makes .tex code could keep doing that.
Helge Hafting
