[reportlab-users] floating point AFM parsing issues, reportlab 2.5-1.1 on ubuntu

[Mark Eichin]

I'm converting a little project from the Cairo PDF support to
reportlab (so far it looks like reportlab is 40 or 50 times faster,
which is nice) but when I go to actually select a font (instead of
just keeping the defaults), it blows up:

File "./try_reportlab.py", line 18, in textself._canvas.setFont("Times", 12)
File"/usr/lib/python2.7/dist-packages/reportlab/pdfgen/canvas.py",
line1549, in setFont
   font = pdfmetrics.getFont(self._fontname)
File"/usr/lib/python2.7/dist-packages/reportlab/pdfbase/pdfmetrics.py",line
689, in getFont
 return findFontAndRegister(fontName)
File"/usr/lib/python2.7/dist-packages/reportlab/pdfbase/pdfmetrics.py",line
671, in findFontAndRegister
 face = getTypeFace(fontName)
File"/usr/lib/python2.7/dist-packages/reportlab/pdfbase/pdfmetrics.py",line
642, in getTypeFace
 afm = bruteForceSearchForAFM(faceName)
File "/usr/lib/python2.7/dist-packages/reportlab/pdfbase/pdfmetrics.py",line
228, in bruteForceSearchForAFM
 topDict, glyphDict =parseAFMFile(possible)
 File"/usr/lib/python2.7/dist-packages/reportlab/pdfbase/pdfmetrics.py",line
110, in parseAFMFile
 width = string.atoi(r)
File"/usr/lib/python2.7/string.py", line 403, in atoi
 return _int(s,base)ValueError: invalid literal for int() with base
10: '316.66667',
while looking for faceName='Times'

Turns out it's opening /usr/share/fonts/X11/Type1/lmssdc10.afm and the line

   C 32 ; WX 316.66667 ; N space ; B 0 0 0 0 ;

is causing the problem; many of the other widths in that font are also
non-integral.  It's looking at this font because
reportlab.rl_config.T1SearchPath contains that Type1 directory - the
font itself is from the "Latin Modern" font set, in the
lmodern2.004.1-3 package.

It looks like this was discussed
inhttp://two.pairlist.net/pipermail/reportlab-users/2005-August/004240.html
(with a different font); an interesting thing about the newer example
is that lmodern is brought in by texlive-base, so it is probably at
least moderately widespread...

Turns out that if I use pdfmetrics.registerFont and pick a TTF file
explicitly, it bypasses the search, and doesn't end up stumbling
across the font it can't handle, which is probably enough of a
workaround for now - and I'm only just working with reportlab for the
first time, maybe it's more common to use explicit references rather
than using system-supplied fonts?
--
_Mark_ <eichin at thok.org> <eichin at gmail.com>