gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] forms with OOo


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] forms with OOo
Date: Sat, 23 Jun 2007 13:18:52 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Thu, Jun 21, 2007 at 01:21:25PM +0200, Philipp Walderdorff wrote:

> > We don't need to *start* OOo for each form. We simply talk
> > to a running OOo. We already have the code for that.
> How does this work? That sounds interesting.

OpenOffice can be started in server mode (which needs to be
done once per machine, say, in the morning). Then, other
software can connect to it via a defined protocol and tell
it to load/manipulate files. We have code to interface OOo
like that and to start a server if none is running.

> I tried to work with OOo and the scanned formular as background. It works. 
> For seldom formulares it seems to be OK.

Yep, see our planned RandomForm feature

        http://wiki.gnumed.de/bin/view/Gnumed/GnumedTodo#RandomForm

> For often filled formulars I would 
> like to have  a quicker and simpler way.
Surely one would prefer a way that is better integrated with
GNUmed itself. However, we also need a user-accessible way
of *adding* forms to GNUmed. This can be done via OOo, too.
The user designs the form in OOo and tells GNUmed a few
things about the form (eg. the OOo template, a name, a
version). GNUmed can then immediately use its existing
interface to OOo to handle that form.

As the list of GNUmed placeholders grows the forms can
become more and more comfortable even if not yet integrated
into GNUmed.

>From the user-defined OOo form the GNUmed team can - if that
makes sense - define integrated forms which can more easily
sport more sophisticated field support.

The design and implementation of this part - integrated
forms - will be heavily influenced by NetEpi which I have
planned to review under that aspect in the next few days.

> In  my program ("waldimed") the solution is:
> Generate a Printfile via INFORMIX(Report) out from Text-Variables (Text) and 
> programmvariables (patient-Datas) and prefabricated Textelements and print 
> this file together with the Background-picture through the mentioned 
> Perl-skript.
The official forms don't need a background printed but
rather need the form content to be printed on pre-made paper
forms.

> I suppose, this should work in gnuMed also.
But only for non-official forms.

> The Perl-Skript or 
> similar code  could be used  or may be a similar python-Solution.
> When filling  the needed text-variables GnuMed can use its phrase-weel.
Absolutely.

> In my "waldimed" the postion of printing the Text-Variables and 
> patient-Datasi  
> maintenance  is coded fix (row/column). This is the simpler way to programm,
Yes, we have tables for that sort of information. NetEpi (as
to my current understanding) uses an XML based definition
which may well be the better solution.

> but has to be done for every Formular and every country and every Change of 
> the formular
Yes.

> and is maintenance intensiv. 
Well, yes.

> The question is, if it would be possible to make a GUI with the scanned 
> background and the user puts his Cursor on the beginning of the 
> Formular-Field, which tells Gnumed the position, where the needed variable 
> will be printed.
This is certainly possible and such software exists. There
is, howver, no prominent FOSS solution for that (I remember
NetEpi researched this question, too) and it's a project in
its own right. Thus, we are likely better off to leverage
OOo to that effect until a better (?) solution arrives.

In OOo one can define a "form template" document which loads
a scan as a background image, defines text areas for writing
into and puts placeholders into them, the latter of which
GNUmed code can then replace with actual data and tell OOo
to print the template instance with or without the
background image. A poor man's form editor.

> In this way every Country could make its own Formulars very 
> simple. The data for that can be copied to all users of that Country. This 
> would be the elegnat way.
Surely.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]