[reportlab-users] parseAFMFile sfsc1200.afm

[Robin Becker]

Gregor Horvath wrote:
> Robin Becker wrote:
> 
>>
>> it's likely that the afm files come with a line ending that isn't nice 
>> on Linux. But if it were a conversion problem I would expect the error 
>> to happen in parseAfmFile.
> 
> 
> Line Endings are on both systems correct.
> 
>>
>>  The _rl_accel setFontInfo call is failing. Was that available under 
>> windows and what versions etc etc.
> 
> 
>  >>> dir(_rl_accel)
> ['Box', 'BoxList', 'Glue', 'Penalty', '_AsciiBase85Decode', 
> '_AsciiBase85Encode'
> , '_SWRecover', '__doc__', '__file__', '__name__', '_instanceEscapePDF', 
> '_insta
> nceStringWidth', '_sameFrag', 'add32', 'calcChecksum', 
> 'defaultEncoding', 'error
> ', 'escapePDF', 'fp_str', 'getFontInfo', 'getFonts', 'hex32', 
> 'setFontInfo', 'st
> ringWidth', 'version']
>  >>> _rl_accel.version
> '0.53'
> 
>>
>> We're passing in the ascent and descent as well, but they would/should 
>> cause a problem under windows as well.
> 
> 
> Sorry I don´t understand this sentence.
> 

in pdfmetrics we have

if _stringWidth:
	_rl_accel.setFontInfo(string.lower(fontName),
		_dummyEncoding,
		font.face.ascent,
		font.face.descent,
		font.widths)

in _rl_accel.c I see

int	ascent, descent;#
.....
if (!PyArg_ParseTuple(args, "ssiiO", &fontName, &encoding, &ascent, 
&descent,&pW)) return NULL;
ie the ascent and descent are supposed to be integers as well as all the widths.

Now if the widths are all ints then still the ascent/descent could also cause 
problems. As I understand it you fixed a line related to the inMetrics section 
of code. There's also the stuff related to inHeader. Can you check the file for 
the words Ascender/Descender and see if they are also non-integer? If so the 
same kind of 'fix' could be applied to the string.atoi() call near line 114.
-- 
Robin Becker