[mod_python] does a mod_python handler exist to generate charts/graphs? (png images)

perry.tew at cibavision.novartis.com wrote:

>David,
>   Thanks for the input.  I'll add chaco and gnuplot.py to the list.  So 
>far I have (in no order):
>
>reportlab
>pygdchart
>chaco
>gnuplot
>
>I'll have to start investigating each of them.  chaco and gnuplot appear 
>to have massive options and functionality.
>  
>
Great. I'm away for the next few days so it'll be interesting to see 
what you find.

>
>In response to your earlier suggestions:
>"""
>This kind of thing is pretty simple, you can either create a 
>StringIO.StringIO object (standard Python) which is a pseudo-file that 
>you can get the contents out of using a string, or you could try passing 
>the request object (at the appropriate time) and see if it will work 
>writing to that.
>Another option (assuming the project is open source) is to alter the 
>program to support returning the data in a string.
>I got the reportlab guys to do this - their project is mainly focussed 
>on Reports and PDF, but it also has charting capabilities I haven't 
>investigated.
>"""
>
>I tried to use the StringIO object from both StringIO and cStringIO.  The 
>library didn't like
>that at all.  I traced some of the pygdchart code.  It drops down into C 
>and calls the following code (from _gdchartc.c)
>( I stripped out some unnecessary lines):
>PyObject *pfile, *labels, *data, *combodata;
>FILE *fp;
>...
>if (!PyArg_ParseTuple(args, "iiO!iiOiOO", &width, &height, &PyFile_Type, 
>&pfile, 
>...
>fp = PyFile_AsFile(pfile);
>
>I so new to python it hurts, but I'm guessing that at this point in a C 
>program, pfile has to be an
>actual pointer to a file and not a file-like interface such as StringIO? 
>Any experience with this?
>
>As for having the author change the interface, I've already emailed them. 
>Later on I found
>the cStringIO functionality listed in a TODO file for the pygdchart 
>library.  Guess I'm not the first...
>I don't know how possible it would be to use cStringIO, since the FILE 
>pointer is passed through a mess of C libraries
>
>gdchart -> gd -> libjpeg
>
>The functions all the way down to libjpeg are wanting a pointer to a FILE 
>structure.   My other thought was
>looking for a way to imitate the FILE pointer in memory and modifying the 
>entry C code to return back the
>in memory data as a binary stream.  I'll have to look into that as well. 
>My C is pretty weak as well.  I'm
>so thankful there's Google.
>
>As a workaround, here's what I did (using os.tmpfile):
>
>from mod_python import apache
>from mod_python import util
>import gdchart
>import os
>
>def handler(req):
>        req.content_type = "image/png"
>
>        chart = gdchart.Line3D()
>        chart.width = 250
>        chart.height = 250
>        chart.xtitle = "xtitle goes here"
>        chart.ytitle = "Percentage"
>        chart.title = "Example Graph"
>        chart.ext_color = [ "white", "yellow", "red", "blue", "green"]
>        chart.setData([20, 100, 80, 30, 50],[10,150,20,25,65])
>        chart.setLabels(["Mon", "Tue", "Wed", "Thu", "Fri"])
>        chart.setLabels(["Mon", "Tue", "Wed", "Thu", "Fri"])
>
>        f = os.tmpfile()
>        chart.draw(f)
>        f.seek(0)
>        req.write(f.read())
>        f.close()
>
>        return apache.OK
>
>It outputs a graph for me.    Here's another question that may be 
>better suited for comp.lang.python, but do you know if
>os.tmpfile() uses an in-memory representation of a file
>or does it use a physical file that just remains anonymous?  I'm 
>concerned about the wasteful loss of speed having to write to
>disk and read it back.
>
>Well, enough rambling.  Thanks for your time,
>Perry Tew
>  
>
I'm pretty sure os.tmpfile() is a real file. It should probably be 
deleted afterwards.
Definitely the better option here is changing the library...
Thanks for the investigations
David