Re: [Gnumed-devel] pyuno on WIndows

[Karsten Hilbert]

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