Re: [Gnumed-devel] pyuno on WIndows

[Karsten Hilbert]

Of course, regarding LO I forgot two more approaches:

Use pyuno (which we do) and "properly" traverse the document
using the OOO document API to insert tables, lists, and text.

I got tired of wrestling with that monstrous Java-like API
(assuming one can even connect to LO which Sebastian had
trouble with in the first place).

The next approach would be to write code (say, Python) to be
run *inside* LO, based on the "internal" Python interpreter.
For one thing, one would either have to re-implement
database access and gmMacro.py etc etc or else one would
have to make the GNUmed code run on Python 3 (which will
need to be done at some point anyway) and then make it
useable from within LO. IOW, have LO access GNUmed rather
than the other way round. This is the approach typically
taken by applications that I know of - it's way too much
work for me, though.

Karsten


On Sun, May 12, 2013 at 10:17:52PM +0200, Karsten Hilbert wrote:
> Date: Sun, 12 May 2013 22:17:52 +0200
> From: Karsten Hilbert <address@hidden>
> To: address@hidden
> Subject: Re: [Gnumed-devel] pyuno on WIndows
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> Back in the days when I implemented the GNUmed/Python-UNO/
> OOO/LO bridge (and when I updated it to work again) I read
> all those links until I started vomiting.
> 
> And those were the days of Python 2.x inside LO - which are
> pretty much over.
> 
> Regardless of how difficult or easy it is to write or not
> write this bridge and whether or not it uses Python 2 or 3
> one CONCEPTUAL basic problem remains:
> 
> How do you create variable length structures like tables or
> lists ?  At the time of creating the template you cannot
> know how many lines or items there will be. So one
> conceptual approach is to say the following inside the
> template:
> 
> HERE_BEGINS_THE_TABLE_IN_OOO_FORMAT
> $placeholder::THIS IS WHAT A TABLE *LINE* LOOKS LIKE INCLUDING %()s TO BE 
> REPLACED BY DATA::length>$
> HERE_ENDS_THE_TABLE_IN_OOO_FORMAT
> 
> GNUmed will then replace $<placeholder>$ and produce not
> just one (like with lastname/firstname) but as many lines as
> needed in the format defined *inside the placeholder*. For
> that to work GNUmed does NOT need to know anything about the
> target format (well, almost, it needs to escape special
> characters). The template writer needs to know and that's
> that.
> 
> This approach has its limits, namely that it can only apply
> formatting that can be defined within the placeholder
> template itself (for example, it cannot include a *literal*
> line break). Also, it cannot apply special formatting (say,
> pathological lab values in red) based on the data - each
> line will be uniform. It is also VERY hard to *skip* (rather
> than "leave empty") missing values with this approach.
> 
> A second approach is to generate the table/list *entirely*
> within GNUmed. The template contains this:
> 
> 
> $placeholder_as_table::format=OOO::999999$
> 
> 
> which will be replaced by a fully formatted, well-formed
> table right there in the source document.
> 
> (never mind the fact that one would have to rig a, say, OOo
> document to accept a whole table right there just so - this
> cannot be done by simply writing a document in OOo)
> 
> This approach *can* apply nearly any formatting based on
> whatever it sees fit. However, it needs to REIMPLEMENT the
> table/list creation code of the target application. This
> typically fails badly -- except in markup languages (or,
> rather, document *definition* languages, which define the
> *what* rather than the *how* of things).
> 
> In fact, this approach has been chosen for a few LaTeX
> output placeholders (curr_meds_tables & friends).
> 
> I will NOT badly re-implement code that already exists
> inside, say, OOo (LO).
> 
> HOWEVER, Jerzy hinted at the fact that he's found a way to
> make this work for LibreOffice which I am very interested to
> see. Given his code so far I won't be surprised if his
> approach works well.
> 
> Karsten
> 
> On Sun, May 12, 2013 at 09:41:12PM +0200, Hilbert, Sebastian wrote:
> > Date: Sun, 12 May 2013 21:41:12 +0200
> > From: Sebastian Hilbert <address@hidden>
> > To: address@hidden
> > Subject: Re: [Gnumed-devel] pyuno on WIndows
> > User-Agent: KMail/4.10.2 (Linux/3.5.0-29-generic; KDE/4.10.2; i686; ; )
> > 
> > Am Sonntag, 12. Mai 2013, 21:26:48 schrieb Sebastian Hilbert:
> > > Hi,
> > > 
> > > We are not currently actively supporting Openoffice or Libroffice. One
> > > person made me aware that pyuno is missing on MS Windows.
> > > 
> > > Found this
> > > 
> > > http://stackoverflow.com/questions/4270962/using-pyuno-with-my-existing-pyth
> > > on-installation
> > > 
> > > I have compiled GNUmed to run on python 2.6 Libreoffice ships python 3.x.
> > > This is never going to work per the above.
> > > 
> > > Please consider checking alternative 2 in the link above to see if that 
> > > can
> > > be a solution for the problem.
> > > 
> > A bunch of helpful links on python related to OpenOffice
> > 
> > http://wiki.openoffice.org/wiki/Python
> > 
> > Sebastian
> 
> > _______________________________________________
> > Gnumed-devel mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/gnumed-devel
> 
> 
> -- 
> GPG key ID E4071346 @ gpg-keyserver.de
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnumed-devel

-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346