On Monday 18 May 2009 05:54:19 pm Paul McNett wrote: > pyt...@bdurham.com wrote: > > Can you share your thoughts on why you chose to base the Dabo report > > writer off of ReportLab vs. the Open Office word processor? > > Well it wasn't either/or. There are other options out there too. I simply > chose something easy to use, written in python, that gave the desired > output (pdf). > > I think there's room to develop different outputs, including open office > writer. The one I've been thinking about is to output to wx.PostscriptDC > and wx.PaintDC, to print directly to a printer and to display on a > wx.Window, respectively. > > > My assumption is that ReportLab removes the dependency of a large > > application like Writer. But Writer might(?) allow you to generate Open > > Office compatible markup that shifts calculations for group height, page > > breaks, headers, footers, etc to the Writer engine vs. your code? > > It would be a different style of output, sure. > > > I haven't tried to automate Writer so I don't know how big the > > integration gap is or how version dependent Writer files are. > > I've never tried automating OpenOffice either, but I know that there's the > pyUno bridge for the purpose. OpenOffice automation is done in Java (yuck) > but I think pyUno lets you write python code to do it. > > Be my guest! :) > > Paul
Like you said there are several solutions out on the web. The ones I found all had java as the base programming language (BIRT, jReport, openOffice). I took a good look at automating openoffice. In fact I found a few examples of automating openOffice written in Python that I played with. But I have to say automating openoffice might have a few advantages but in general just a pain. Actually, not much different than coding for Word or Excel (in a general way). But really what are those advantages? The developer has access to Writer and Calc (and of course all the other openOffice tools). There are two ways to control openOffice the built-in scripting language (like VBA) and pyUNO. The first required I learn yet another language. So I ruled that out. The second worked but required that I learn enough of the feature set of openOffice to cause me to reconsider. I have coded for Word and Excel in the past. And my memories were that it was a PITA. And last - I had to have openOffice installed somewhere (openOffice will work a server). Believe it or not but some of my client don't want to let go of M$. But one big is openOffice can print to almost any printer and almost anywhere there is a connection. But let's assume that ReportDesigner and reportWriter are working as expected. Then all I have to learn is - Hmmm - Nothing! It uses all the Dabo stuff from the start. The biggest issue is reportWriter does not print - it only creates PDF files and of course no spreadsheets. However, the last statement turns out not to be exactly correct. Viewers and therefore printing are ubiquitous for PDF's. Acroread, kPDF, and many others are available free and normally installed. Turns out printing a PDF from python for Linux, Mac, and Windows is very easy. Take a look at win32print for you windows guys and cups for linux and Mac. So that just leaves spreadsheets. Currently we are using xlwt which is about the same amount of work to produce a spreadsheet as it was with Excel. And of course it will require something like openOffice or Excel to print or view. I haven't found a solution around this problem - but I hope too. Anyway, the above was my thinking and that's what we are using. -- John Fabiani _______________________________________________ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/200905181846.37333.jfabi...@yolo.com
