[reportlab-users] PDFs generated by ReportLab not printing

Robin Becker robin at reportlab.com
Tue May 26 05:22:30 EDT 2009

King Simon-NFHD78 wrote:

>> -----Original Message-----

>> From: King Simon-NFHD78

>> Sent: 22 May 2009 15:15

>> To: 'Support list for users of Reportlab software'

>> Subject: RE: [reportlab-users] PDFs generated by ReportLab

>> not printing


>> In case anyone is still following this thread, the error

>> sounds suspiciously similar to the one described at

>> http://pdfsharp.s3.bizhat.com/pdfsharp-ftopic339.html, which

>> suggests that for Unicode fonts, you have to set the font

>> encoding to Unicode. I'll see if I can figure out how to do that.


> I'm still confused. As far as I can tell, TrueType fonts contain their

> own encoding information, so there should be no need to specify an

> encoding.


> My simple PDF contains this:


> % Font Arial Unicode MS subset 0

> << /BaseFont /AAAAAA+ArialUnicodeMS

> /FirstChar 0

> /FontDescriptor 6 0 R

> /LastChar 127

> /Name /F2+0

> /Subtype /TrueType

> /ToUnicode 4 0 R

> /Type /Font

> /Widths [ 1000

> 1000

> 1000

> ... Etc


> There is no /Encoding key in there, but I've no idea whether there

> should be.


as we currently handle TTF fonts we are creating subsets each with their own
encoding vector. Text using the font uses this encoding vector instead of a more
standard form. We also create and output the ToUnicode object ie a mapping from
our subset to unicode. I believe that's to allow for translation of our encoded
strings into unicode for searching etc etc.

FWIW I think the default is to have the first 128 entries of our first subset be
equivalent to ascii 0-127. That allows for readability of the text strings in a
common case.
Robin Becker

More information about the reportlab-users mailing list