On Wednesday 26 March 2008 03:58:47 pm Rich Shepard wrote:
> This is not specifically LyX, but LaTeX. I ask for your indulgence. :-)
>
> Many moons ago I asked for opinions on using LaTeX as a report tool for
> a python application (a mathematical model, to be more precise), and
> finally decided that ReportLab would be the better solution. However,
> having learned RL and started using it, I see the shortcomings. For the
> record, there are two that concern me: 1) a very limited set of built-in
> PostScript fonts and 2) graphics support that is primarily bit-mapped and
> not vector based. The former means using Times (ugly, IMNSHO) and the
> latter means writing .pdf files of plots, then appending them to the rear
> of the generated ReportLab document. RL is really good as a database report
> writer, but that's not really how I'm using it.
>
> It occurred to me this afternoon that I can write a LaTeX doc preamble
> and save it as a python string, wrap what I want written to the report in
> LaTeX markup (pre-written strings), generate the plots as .eps files, then
> programmatically call latex, dvips, and ps2pdf when the reports are
> finished. Probably the report class would be most appropriate.
>
> Has anyone done this? Our model is written in Python, so we can use the
> open() and write() methods to squirt strings to a disk file. The output
> would look good, and I'd have a lot of flexibility in structuring the
> reports.
Not directly related to your task but ...
Some years ago I used perl to satisfy the need for an Insurance Co to write
standard letters to a client in processing claims, renewals, etc of policies.
This was a challenge because the amount of interpolated comment was derived
from a database and was unpredictable in size.
My approach was to create a LyX template with PERL { ... } pieces in the text
and ${colname} expressions interspersed in the appropriate places.
When the user created a new standard letter, (s)he ran a merge command which
basically supplied a list of database records, and the LyX filename to a perl
program which read the database record (which was a set of variable
assignments of the form ${firstname}='John' ) and replaced the ${tags} with
the data. When it encountered a PERL tag it executed the {} delimited perl
code and fed its output into the final LyX file. For example, the PERL
statements might be {LyxTable("select * from claims where client=$client")}
The perl library function (written by me) would output LyX source for a table
holding the rows of data).
No doubt a future upgrade of LyX will break this code (because of changes to
the underlying table structure of LyX documents). This has already happened
once when LyX changed to the semi-xml format they now use. But I will cope.
The perl script produced an instance of the standard letter for each database
record all in a single file.
The merge program also executed PERL command embedded in the LyX template to
produce things like tables of covers, or payment installments etc. For these
I used the perl access functions provides with LyX and added my own by
reverse engineering LyX tables.
It all works brilliantly. I used perl because I knew it, and also because its
use of $name made it easy for perl to read interpret and write a file.
The output is truly impressive - beautifully typeset regardless of variations
in the interpolated content including tables of data.
This mechanism allows the users to alter the LyX template as their
requirements change without breaking the merge capabilities (provided they
don't mess up the perl interpolations).
No doubt the same sort of thing can be done with Python.
One of the difficulties with Python I foresee are that its reliance on
indentation might be broken by LyX collapsing consecutive spaces.
So you would need to have the tail wag the dog. The python program would have
to be the master and hold the LyX components of the documents for melding in
with your generated report matter.
So my advice. Do it with LyX rather than LaTeX. It makes it easier to play
with your output file using LyX rather than attacking .tex file with vi.
regards
John O'Gorman
>
> Thoughts?
>
> Rich
