[reportlab-users] CPU Loop in graphics caused by uppercase font filename

[Roger]

Robin Becker wrote:

> Roger wrote:

>   

>> I an a relatively new user and have been using the Reportlab 2.0 

>> graphics package to produce vertical bar charts.  Yesterday I tried to 

>> change the default font from Times-Roman to Helvetica by passing a 

>> fontName parameter (on Windows/XP):

>>     lab = Label(fontName='Helvetica')

>>

>> .......

>>

>> Roger

>>     

> I have the same fonts and in my case I have the

> symbol and dingbats fonts with uppercase names. Is it possible to post a simple 

> example script that causes the problem since its not happening for those fonts?

>   

Yes, _fontdata.py has a value for zapfdingbats of Zd______, but my font 
filenames are ZD______.PFB and ZD______.PFM.  The differences in case 
seem to have some relationship with the looping problem.

After some more testing, I found I was mistaken about the loop being in 
Reportlab graphics, instead it occurred later in a call to renderPM.  I 
have a solution that seems to resolve the problem, but I still don't 
fully understand the relationship of the filename case.

The problem seems to have been a race condition, and was set up by a web 
page having two links to different PNG graph images that are created 
upon demand.  The same Webware WebKit servlet is used to produce the PNG 
graphs based upon the incoming CGI data. Per my googling, renderPM is 
not thread-safe.  The solution was to put a lock around the call to 
renderPM.drawToFile:

def makePng(drawing):
    '''Convert a drawing to a PNG image and return it.'''
    makePngLock.acquire()
    sf = StringIO.StringIO('')
    renderPM.drawToFile(drawing, sf,'PNG')
    png = sf.getvalue()
    makePngLock.release()
    return png

Prior to putting in the lock I never saw the problem when using fonts 
with filenames that had matched case, but had consistent failures when 
using fonts with case mis-matched filenames.  Is it possible that the 
mis-matched case in the font filenames is causing a reload of the font 
that is not performed when the case matches?  That would be a plausible 
explanation for the consistency for the success-failure related to fonts 
used -- the first incoming request is slowed by I/O so the second 
request always catches up and causes the threading problem.

Sorry for the initial mis-information.

Roger