On Thu, 09 Jul 2015 22:10:35 +0200 Georg Baum <georg.b...@post.rwth-aachen.de> wrote:
> Steve Litt wrote: > > > On Wed, 8 Jul 2015 06:24:52 +0000 (UTC) > > Ian <iank...@gmail.com> wrote: > > > >> Hi > >> > >> I want to automatically update latex code embedded in a LyX > >> document that was produced as output from another program, in my > >> case STATA. The Latex code contains table commands. > >> > >> The concept is similar to handling graphics in LyX: Insert >> > >> Graphic > >> >> (attach file). If I change the graphic file content, keeping the > >> >> file name > >> and location the same, the graphic image will automatically update > >> in LyX. I want to do the same thing, but with a .tex file in which > >> contains the Latex code for a table produced by STATA. The .tex > >> file name and location remain constant, but the content changes. > >> > >> I am sure this is an easy thing, but I just can't seem to find it > >> on the web forums. > > This is possible: LyX has a mechanism called "external templates" > which can be seen as a generalization of the graphics inset: With an > external template, you can tell LyX what it needs to do to convert > your STATA file into LaTeX, and you also tell it how this LaTeX is to > be included in the LyX document. The only requirement for this to > work is that your application (or any other tool) allows to convert > to LaTeX from the command line. > > If you want to use this feature, you need to do two things: > > 1) Define a new external template for STATA as explained in chapter 6 > "6 Including External Material" in the Customization Manual. This > neds to be once, and if you need help don't hesitate to ask on the > list. > > 2) Each time you want to include a STATA output, you use Insert -> > File -> External Material. > > > > I do that kind of stuff all the time. The trick is to put some kind > > of an unmistakable token in your LyX doc. Then make a shellscript > > that cats your LyX into a script (I'd probably use AWK, your > > mileage may vary) to replace the token with the desired LaTeX, and > > then redirect the script's output to another LyX file. LyX --export > > latex tempfile.lyx;pdflatex tempfile.tex. > > This is certainly technically interesting, but I would not recommend > such a procedure to the original poster, since the builtin mechanism > does not need those helper scripts, and all the export/view buttons > in LyX do just work. I'm not so sure it I wouldn't recommend it for the Original Poster (OP). I've been using these techniques for years, and they amount to a 1 click (or menu choice or command) complete process. It could be automated to do every hour on the hour with no point and click intervention. It doesn't depend on LyX features and won't break if LyX changes its internal way of doing stuff. It's very simple to troubleshoot, given that there's an intermediate file. And it's dead bang easy for anyone who can script Python at all. I think it boils down to a philosophical point. Some folks believe strongly in never reinventing the wheel. I certainly use a lot of wheels as-is, but I always resist incorporating a wheel if all I need is one little spoke. Dependencies, even on something you've already incorporated, have a cost. I have scripts that create personalized eBooks, with the buyer's name in the footers, and some other security features I can't discuss. I make and ship these several times a day, and all I need to do is tell my converter which books to convert, the person's name, and bang, it makes all the eBooks in the order. LyX's only involvement is in a shellscript using its --export feature. If the OP can do simple scripting, I'd personally recommend preprocessing over LyX-centric ways of doing it, if the LyX-centric ways are complex, time consuming (in a point and click sense), or likely to change with a future LyX version. SteveT Steve Litt July 2015 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
