On Tuesday 23 September 2003 8:32 am, Helge Hafting wrote:
> After reading the document, I wonder what the \executeIfFound is for.
> I see what it _does_, but why let latex handle an error condition?
> Isn't it better to simply give a message through the GUI
> (Your figure doesn't exist/failed to convert)
> This is much faster as the error is reported so early
> that latex don't have to run at all.
> Do we want to generate a .dvi/.ps/.pdf at all in
> such a case?
>
> An ability to skip some figures might be handy of course,
> but shouldn't that be explicit? I.e. the user click some
> "no output" button in the external inset, (or a global "draft" thing)
> and then lyx don't produce any latex at all for the inset?
>
> I'm a bit worried about the user who thinks a large document
> printed fine, only to discover later that the tricky
> figure on page 67 was silently omitted.
Well, two points:
1. We already do exactly that with \includegraphics, passing it the draft
option if the file is not found.
2. In this particular instance, the figure will not be 'silently' omitted
because the \warnNotFound macro posts a warning in the LaTeX log file. Ok, so
we might need a dialog to pop up and tell us that the log file says it
couldn't find 44 external files.
So, were we to move InsetGraphics into InsetExternal, things would certainly
be no worse in this regard.
Nonetheless, this is a point well made. In fact, Jean-Marc has already made
it. I think that we will end up with an external template language that has
ProductFound "\\input{$$BaseName.pstex_t}"
ProductNotFound "\\warnNotFound{$$BaseName.pstex_t}"
the check will be performed by LyX, which will also check whether a
ProductNotFound entry is present. If it is, it'll execute it. If it isn't,
it'll bomb.
The idea is to make it easy for you, the user, to tune this behaviour. It is
much easier to modify a text file than to change the source and recompile.
Meanwhile, these more complex macros like \executeIfFound are just what we
need to ensure that we can cope with the esoterica that users might throw at
us. It'd be pretty lame to say that we have an InsetExternal that can handle
everything except your particular example, now wouldn't it?
In fact, I think I have a language that can handle these modifiers
successfully. We have to tell it explicitly that the modifier is a command
(has a beginning '\foo{' and an end '}') or is an option and where to place
these modifiers. What we don't have to tell the language is what these
beginnings, ends and options contain. Indeed, in the general case we cannot.
Instead, we have to tell the language which classes to instantiate.
Example of modifier commands in action:
Template XFig
GuiName "XFig: $$Basename"
InputFormat fig
AutomaticProduction true
Modifiers Rotate, Resize
Format LaTeX
ModifierCommand Rotate RotationLatexCommand
ModifierCommand Resize ResizeLatexCommand
Product
"$$RotateBegin$$ResizeBegin\\input{$$Basename.pstex_t}$$ResizeEnd$$RotateEnd"
UpdateFormat pstex
UpdateResult "$$Basename.pstex_t"
Requirement "graphicx"
FormatEnd
TemplateEnd
Example of modifier options in action:
Template RasterImage
GuiName "Image: $$FName"
InputFormat "*"
AutomaticProduction true
Modifiers Rotate, Resize, Clip, Extra
Format LaTeX
ModifierOption Rotate RotationLatexOption
ModifierOption Resize ResizeLatexOption
ModifierOption Clip ClipLatexOption
ModifierOption Extra ExtraLatexOption
Options "$$Extra$$Rotate$$Resize$$Clip"
Product "\\includegraphics$$Options{$$Basename}"
UpdateFormat eps
UpdateResult "$$Basename.eps"
Requirement "graphicx"
FormatEnd
TemplateEnd
Needless to say, I'd like suggestions on how to improve any of this...
Angus
