From dfh at forestfield.co.uk  Mon Nov  2 03:35:53 2009
From: dfh at forestfield.co.uk (David Hughes)
Date: Mon, 02 Nov 2009 08:35:53 +0000
Subject: [reportlab-users] restart page numbering
In-Reply-To: <c361da770910311151g113c5e65h9537fb6b8d8b60ac@mail.gmail.com>
References: <c361da770910311151g113c5e65h9537fb6b8d8b60ac@mail.gmail.com>
Message-ID: <4AEE99E9.5010401@forestfield.co.uk>

Jeffrey O'Neill wrote:
> I have a document with a title page, a TOC page, and then body pages
> with the substance of the report.  I do the page numbers using
> platypus, and have set the page templates so that only the body pages
> have page numbers on them.
>
> Currently, the first body page starts with page number 3.  Is there a
> way to change this so that the first body page is number 1?
>   
Please don't do that ;-)

One of my pet hates is to read a PDF document where the page numbers in 
the TOC are not the same as the physical page numbers the browser uses 
for navigation.

Regards,

David Hughes
Forestfield Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091102/a67d7298/attachment.html>

From andy at reportlab.com  Mon Nov  2 04:20:05 2009
From: andy at reportlab.com (Andy Robinson)
Date: Mon, 2 Nov 2009 09:20:05 +0000
Subject: [reportlab-users] restart page numbering
In-Reply-To: <c361da770910311151g113c5e65h9537fb6b8d8b60ac@mail.gmail.com>
References: <c361da770910311151g113c5e65h9537fb6b8d8b60ac@mail.gmail.com>
Message-ID: <956003ae0911020120s2d7f6fd4jd2d7c1167084042b@mail.gmail.com>

2009/10/31 Jeffrey O'Neill <jeff.oneill at openstv.org>:
> I have a document with a title page, a TOC page, and then body pages
> with the substance of the report. ?I do the page numbers using
> platypus

What exactly do you mean by this?  If you're ultimately doing
  canvas.drawString(canvas.getPageNumber())
inside a callback, you can substract 2 there.   If you're doing
something else, show us the code that creates the page number and
we'll show you how to do it.

Best Regards,

-- 
Andy Robinson
CEO/Chief Architect
ReportLab Europe Ltd.
Media House, 3 Palmerston Road, Wimbledon, London SW19 1PG, UK
Tel +44-20-8545-1570

From cljacobsen at gmail.com  Mon Nov  2 05:26:50 2009
From: cljacobsen at gmail.com (Christian Jacobsen)
Date: Mon, 2 Nov 2009 11:26:50 +0100
Subject: [reportlab-users] restart page numbering
In-Reply-To: <4AEE99E9.5010401@forestfield.co.uk>
References: <c361da770910311151g113c5e65h9537fb6b8d8b60ac@mail.gmail.com>
	<4AEE99E9.5010401@forestfield.co.uk>
Message-ID: <d61c98f70911020226w6827726cg2a1bc4da183c0995@mail.gmail.com>

2009/11/2 David Hughes <dfh at forestfield.co.uk>:
>> Jeffrey O'Neill wrote:
>
>> Currently, the first body page starts with page number 3.  Is there a
>> way to change this so that the first body page is number 1?
>
> Please don't do that ;-)
>
> One of my pet hates is to read a PDF document where the page numbers in the
> TOC are not the same as the physical page numbers the browser uses for
> navigation.

There is absolutely nothing wrong with restarting the page numbers
printed in a PDF. I agree that it is annoying when the logical page
numbering (what the PDF viewer thinks a page number is) does not match
up with what is printed on the page. Luckily this is reasonably easy
to get around using PDFPageLabels:
http://www.reportlab.org/apis/reportlab/reportlab.pdfbase.pdfdoc.PDFPageLabel-class.html

See also the PDF standard section 8.3.1 on "Page Labels" (page 481):
http://www.adobe.com/devnet/pdf/pdfs/PDFReference.pdf
Incidentally you will notice if you open up that document in a PDF
viewer, that roman numerals are displayed up front and arabic
numbering only starts well into the document. Jumping to page 481 in
your PDF viewer will get you to the right place in the document (where
as counting 481 physical pages from the first page in the document
wont).

Here is example usage (using the addPageLabel helper in
reportlab.pdfgen.canvas):
-------------8<-------------------8<-------------------8<------------------
from reportlab.pdfgen import canvas
from reportlab.lib.units import cm
c = canvas.Canvas("page_numbering.pdf")
c.addPageLabel(c.getPageNumber()-1, 'ROMAN_LOWER')
for num in ['i', 'ii', 'iii', 'iv', 'v']:
    c.drawString(3*cm, 3*cm, num)
    c.showPage()
c.addPageLabel(c.getPageNumber()-1, 'ARABIC')
for num in range(1,5):
    c.drawString(3*cm, 3*cm, str(num))
    c.showPage()
c.addPageLabel(c.getPageNumber()-1, 'ARABIC', 10)
for num in range(10,15):
    c.drawString(3*cm, 3*cm, str(num))
    c.showPage()
c.addPageLabel(c.getPageNumber()-1, 'ARABIC', prefix='A.')
for num in range(1,5):
    c.drawString(3*cm, 3*cm, 'A.' + str(num))
    c.showPage()
c.save()
-------------8<-------------------8<-------------------8<------------------

Christian

From ralsina at netmanagers.com.ar  Mon Nov  2 05:34:52 2009
From: ralsina at netmanagers.com.ar (Roberto Alsina)
Date: Mon, 2 Nov 2009 07:34:52 -0300
Subject: [reportlab-users] restart page numbering
In-Reply-To: <4AEE99E9.5010401@forestfield.co.uk>
References: <c361da770910311151g113c5e65h9537fb6b8d8b60ac@mail.gmail.com>
	<4AEE99E9.5010401@forestfield.co.uk>
Message-ID: <200911020734.52405.ralsina@netmanagers.com.ar>

On Monday 02 November 2009 05:35:53 David Hughes wrote:
> Jeffrey O'Neill wrote:
> I have a document with a title page, a TOC page, and then body pages
> with the substance of the report.  I do the page numbers using
> platypus, and have set the page templates so that only the body pages
> have page numbers on them.
> 
> Currently, the first body page starts with page number 3.  Is there a
> way to change this so that the first body page is number 1?
> 
> Please don't do that  ;-)
> 
>  One of my pet hates is to read a PDF document where the page numbers in
>  the TOC are not the same as the physical page numbers the browser uses for
>  navigation.

This is good practice for printed documents, though.

-- 
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  KDE Developer (MFCH)
 (_Y_.)' ._   ) `._`.  " -.-'  http://lateral.netmanagers.com.ar 
  _..`-'_..-_/ /-'_.'     The 6,855th most popular site of Slovenia   
(l)-'' ((i).' ((!.'       according to alexa.com (27/5/2007) 

From robin at reportlab.com  Mon Nov  2 05:47:18 2009
From: robin at reportlab.com (Robin Becker)
Date: Mon, 02 Nov 2009 10:47:18 +0000
Subject: [reportlab-users] Bug in invariant?
In-Reply-To: <200910311702.19010.ralsina@netmanagers.com.ar>
References: <200910311702.19010.ralsina@netmanagers.com.ar>
Message-ID: <4AEEB8B6.8030602@chamonix.reportlab.co.uk>

Thanks for this report; certainly didn't know about the timezone issue. I'll try 
and get this into the repository today.


Roberto Alsina wrote:
> Hello, when trying to generate PDFs with invariant=1 in local_rl_config.py so 
> that tests don't fail because of timestamps in rst2pdf we found that files 
> still were different when generated by two persons.
> 
> And the difference was this:
> 
> $ ls -l 65* 
> -rw-r--r-- 1 ralsina users 16703 2009-10-31 16:34 65_patrick.pdf 
> -rw-r--r-- 1 ralsina users 16703 2009-10-31 16:35 65_roberto.pdf 
> 
> The only difference between them is... 
> 
>  /CreationDate (D:20000101000000+06'00') 
> 
>  /CreationDate (D:20000101000000+03'00')
> 
> As you can see, the date is being fixed, but the timezone is not. I suspect 
> when the support for gmt offset was added, this slipped.
> 
> The fix is to change PDFDate like this (or something similar):
> 
> class PDFDate:
>     __PDFObject__ = True
>     # gmt offset now suppported
>     def __init__(self, invariant=rl_config.invariant, dateFormatter=None):
>         if invariant:
>             now = (2000,01,01,00,00,00,0)
>             self.dhh = 0; self.dmm = 0
>         else:
>             import time
>             now = tuple(time.localtime(_getTimeStamp())[:6])
>             from time import timezone
>             self.dhh, self.dmm = timezone // 3600, (timezone % 3600) % 60
>         self.date = now[:6]
>         self.dateFormatter = dateFormatter
> 
>     def format(self, doc):
>         dfmt = self.dateFormatter or (
>                 lambda yyyy,mm,dd,hh,m,s:
>                     "D:%04d%02d%02d%02d%02d%02d%+03d'%02d'" % 
> (yyyy,mm,dd,hh,m,s,self.dhh,self.dmm))
>         return format(PDFString(dfmt(*self.date)), doc)
> 
> 


-- 
Robin Becker

From robin at reportlab.com  Mon Nov  2 05:47:18 2009
From: robin at reportlab.com (Robin Becker)
Date: Mon, 02 Nov 2009 10:47:18 +0000
Subject: [reportlab-users] Bug in invariant?
In-Reply-To: <200910311702.19010.ralsina@netmanagers.com.ar>
References: <200910311702.19010.ralsina@netmanagers.com.ar>
Message-ID: <4AEEB8B6.8030602@chamonix.reportlab.co.uk>

Thanks for this report; certainly didn't know about the timezone issue. I'll try 
and get this into the repository today.


Roberto Alsina wrote:
> Hello, when trying to generate PDFs with invariant=1 in local_rl_config.py so 
> that tests don't fail because of timestamps in rst2pdf we found that files 
> still were different when generated by two persons.
> 
> And the difference was this:
> 
> $ ls -l 65* 
> -rw-r--r-- 1 ralsina users 16703 2009-10-31 16:34 65_patrick.pdf 
> -rw-r--r-- 1 ralsina users 16703 2009-10-31 16:35 65_roberto.pdf 
> 
> The only difference between them is... 
> 
>  /CreationDate (D:20000101000000+06'00') 
> 
>  /CreationDate (D:20000101000000+03'00')
> 
> As you can see, the date is being fixed, but the timezone is not. I suspect 
> when the support for gmt offset was added, this slipped.
> 
> The fix is to change PDFDate like this (or something similar):
> 
> class PDFDate:
>     __PDFObject__ = True
>     # gmt offset now suppported
>     def __init__(self, invariant=rl_config.invariant, dateFormatter=None):
>         if invariant:
>             now = (2000,01,01,00,00,00,0)
>             self.dhh = 0; self.dmm = 0
>         else:
>             import time
>             now = tuple(time.localtime(_getTimeStamp())[:6])
>             from time import timezone
>             self.dhh, self.dmm = timezone // 3600, (timezone % 3600) % 60
>         self.date = now[:6]
>         self.dateFormatter = dateFormatter
> 
>     def format(self, doc):
>         dfmt = self.dateFormatter or (
>                 lambda yyyy,mm,dd,hh,m,s:
>                     "D:%04d%02d%02d%02d%02d%02d%+03d'%02d'" % 
> (yyyy,mm,dd,hh,m,s,self.dhh,self.dmm))
>         return format(PDFString(dfmt(*self.date)), doc)
> 
> 


-- 
Robin Becker

From dfh at forestfield.co.uk  Mon Nov  2 06:12:53 2009
From: dfh at forestfield.co.uk (David Hughes)
Date: Mon, 02 Nov 2009 11:12:53 +0000
Subject: [reportlab-users] restart page numbering
In-Reply-To: <d61c98f70911020226w6827726cg2a1bc4da183c0995@mail.gmail.com>
References: <c361da770910311151g113c5e65h9537fb6b8d8b60ac@mail.gmail.com>	<4AEE99E9.5010401@forestfield.co.uk>
	<d61c98f70911020226w6827726cg2a1bc4da183c0995@mail.gmail.com>
Message-ID: <4AEEBEB5.9080306@forestfield.co.uk>

Christian Jacobsen wrote:
> 2009/11/2 David Hughes <dfh at forestfield.co.uk>:
>   
>>> Jeffrey O'Neill wrote:
>>>       
>>> Currently, the first body page starts with page number 3.  Is there a
>>> way to change this so that the first body page is number 1?
>>>       
>> Please don't do that ;-)
>>
>> One of my pet hates is to read a PDF document where the page numbers in the
>> TOC are not the same as the physical page numbers the browser uses for
>> navigation.
>>     
>
> There is absolutely nothing wrong with restarting the page numbers
> printed in a PDF. I agree that it is annoying when the logical page
> numbering (what the PDF viewer thinks a page number is) does not match
> up with what is printed on the page. Luckily this is reasonably easy
> to get around using PDFPageLabels:
> http://www.reportlab.org/apis/reportlab/reportlab.pdfbase.pdfdoc.PDFPageLabel-class.html
>
> See also the PDF standard section 8.3.1 on "Page Labels" (page 481):
> http://www.adobe.com/devnet/pdf/pdfs/PDFReference.pdf
Thanks for showing me the difference between page labels and indices and 
allow me to withdraw the first sentence of my post. My pet hate still 
stands, even though my simplistic explanation of it was flawed.
--
Regards,
David Hughes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091102/6ea9621c/attachment.html>

From gherman at darwin.in-berlin.de  Mon Nov  2 08:16:48 2009
From: gherman at darwin.in-berlin.de (Dinu Gherman)
Date: Mon, 02 Nov 2009 14:16:48 +0100
Subject: [reportlab-users] Fate of bugs reported for AreaLinePlot?
Message-ID: <20091102141648.10547bjjczqd4v5s@webmail.in-berlin.de>

Hi,

I'm just curious to know if there is any chance to get the
bugs I reported more or less recently for AreaLinePlot
fixed before the end of the year (2009)? My client would
appreciate it.

Thanks,

Dinu



From ralsina at netmanagers.com.ar  Mon Nov  2 08:24:38 2009
From: ralsina at netmanagers.com.ar (Roberto Alsina)
Date: Mon, 2 Nov 2009 10:24:38 -0300
Subject: [reportlab-users] Bug in invariant?
In-Reply-To: <4AEEB8B6.8030602@chamonix.reportlab.co.uk>
References: <200910311702.19010.ralsina@netmanagers.com.ar>
	<4AEEB8B6.8030602@chamonix.reportlab.co.uk>
Message-ID: <200911021024.38465.ralsina@netmanagers.com.ar>

On Monday 02 November 2009 07:47:18 Robin Becker wrote:
> Thanks for this report; certainly didn't know about the timezone issue.
>  I'll try  and get this into the repository today.

Not so surprising you never caught it, this bug only appears when you need to 
generate invariant PDFs by two people on different timezones. I don't expect 
your test setup tries to do that :-D

-- 
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  KDE Developer (MFCH)
 (_Y_.)' ._   ) `._`.  " -.-'  http://lateral.netmanagers.com.ar 
  _..`-'_..-_/ /-'_.'     The 6,855th most popular site of Slovenia   
(l)-'' ((i).' ((!.'       according to alexa.com (27/5/2007) 

From ralsina at netmanagers.com.ar  Mon Nov  2 08:25:32 2009
From: ralsina at netmanagers.com.ar (Roberto Alsina)
Date: Mon, 2 Nov 2009 10:25:32 -0300
Subject: [reportlab-users] restart page numbering
In-Reply-To: <d61c98f70911020226w6827726cg2a1bc4da183c0995@mail.gmail.com>
References: <c361da770910311151g113c5e65h9537fb6b8d8b60ac@mail.gmail.com>
	<4AEE99E9.5010401@forestfield.co.uk>
	<d61c98f70911020226w6827726cg2a1bc4da183c0995@mail.gmail.com>
Message-ID: <200911021025.32087.ralsina@netmanagers.com.ar>

On Monday 02 November 2009 07:26:50 Christian Jacobsen wrote:
> There is absolutely nothing wrong with restarting the page numbers
> printed in a PDF. I agree that it is annoying when the logical page
> numbering (what the PDF viewer thinks a page number is) does not match
> up with what is printed on the page. Luckily this is reasonably easy
> to get around using PDFPageLabels:
> http://www.reportlab.org/apis/reportlab/reportlab.pdfbase.pdfdoc.PDFPageLab
> el-class.html

Just wanted to post a thank you: I didn't know about this feature, and it just 
made rst2pdf a little bit better :-)

-- 
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  KDE Developer (MFCH)
 (_Y_.)' ._   ) `._`.  " -.-'  http://lateral.netmanagers.com.ar 
  _..`-'_..-_/ /-'_.'     The 6,855th most popular site of Slovenia   
(l)-'' ((i).' ((!.'       according to alexa.com (27/5/2007) 

From andy at reportlab.com  Mon Nov  2 08:31:20 2009
From: andy at reportlab.com (Andy Robinson)
Date: Mon, 2 Nov 2009 13:31:20 +0000
Subject: [reportlab-users] Fate of bugs reported for AreaLinePlot?
In-Reply-To: <20091102141648.10547bjjczqd4v5s@webmail.in-berlin.de>
References: <20091102141648.10547bjjczqd4v5s@webmail.in-berlin.de>
Message-ID: <956003ae0911020531n6448e49auea9fb0f4901632ce@mail.gmail.com>

2009/11/2 Dinu Gherman <gherman at darwin.in-berlin.de>:
> Hi,
>
> I'm just curious to know if there is any chance to get the
> bugs I reported more or less recently for AreaLinePlot
> fixed before the end of the year (2009)? My client would
> appreciate it.
.

At the time of the report, we only had one person available who knew
the chart code and he was very busy.   Luckily half our team has been
doing charting work in October (although not on this class) and are
past the urgent stage, there's a good chance we can do these in
November.

However, I would personally classify them more as 'enhancement
requests' than 'bugs'..

For a guaranteed response you could (a) send patches in, or (b) email
me directly and we can agree a modest price and deadline to fix.

-- 
Andy Robinson
CEO/Chief Architect
ReportLab Europe Ltd.
Media House, 3 Palmerston Road, Wimbledon, London SW19 1PG, UK
Tel +44-20-8545-1570

From Robert at AbilitySys.com  Tue Nov  3 09:34:54 2009
From: Robert at AbilitySys.com (Robert Young)
Date: Tue, 3 Nov 2009 06:34:54 -0800
Subject: [reportlab-users] Page headings in platypus
Message-ID: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>

Sorry if this is a repost, I didn't see an echo so I don't know if it
made it through the first time...

 

 

I am trying to write code that will place a "continued" heading on a
page. I have added all the "paragraphs" to a "story" and once they are
all added, I use the build method and can place global page headers with
no p[problem. However, I want to add a section heading when the data
flows on to the next page. For example, the data looks like this:

 

Section 1

  Line 1

  Line 2

  Line 3

  ...

  Line n

Section 2

  Line 1

  Line 2

  Line 3

  ...

  Line n

 

When a section flows on to a new page, I want to add the heading
"Section 1 (continued)." The problem is, the pagination occurs long
after the "story" is built, so I have no idea where the break is
occurring, and I don't really want to hard code a break anyhow.

 

How can I detect during the build where a break occurs, and how can I
determine the appropriate data to print at that time? Is there such an
attribute as a paragraph header?

 

Thanks in advance,

 

-      Robert

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091103/df35529c/attachment.html>

From robin at reportlab.com  Tue Nov  3 11:53:12 2009
From: robin at reportlab.com (Robin Becker)
Date: Tue, 03 Nov 2009 16:53:12 +0000
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>
Message-ID: <4AF05FF8.6060503@chamonix.reportlab.co.uk>




Robert Young wrote:



I am trying to write code that will place a "continued" heading on a
> page. I have added all the "paragraphs" to a "story" and once they are
> all added, I use the build method and can place global page headers with
> no p[problem. However, I want to add a section heading when the data
> flows on to the next page. For example, the data looks like this:
>  

There is a gadget in flowables.py that attempts this sort of thing. It's called 
PTOContainer and attempts to do injection of specified lists into the flow when 
it is split. (PTO stands for "Please Turn Over"). Personally I hate it as it's 
full of edge cases and bugs. For your case I guess you need to do something like

story.append(PTOContainer([section1flowables],header=[ContinuedSection1Flowables])

give it a whirl and see what happens.

> 
> Section 1
> 
>   Line 1
> 
>   Line 2
> 
>   Line 3
> 
>   ...
> 
>   Line n
> 
> Section 2
> 
>   Line 1
> 
>   Line 2
> 
>   Line 3
> 
>   ...
> 
>   Line n
> 
>  
> 
> When a section flows on to a new page, I want to add the heading
> "Section 1 (continued)." The problem is, the pagination occurs long
> after the "story" is built, so I have no idea where the break is
> occurring, and I don't really want to hard code a break anyhow.
> 
>  
> 
> How can I detect during the build where a break occurs, and how can I
> determine the appropriate data to print at that time? Is there such an
> attribute as a paragraph header?
> 
>  
.....

-- 
Robin Becker

From IStevens at globeandmail.com  Tue Nov  3 18:02:59 2009
From: IStevens at globeandmail.com (Stevens, Ian)
Date: Tue, 3 Nov 2009 18:02:59 -0500
Subject: [reportlab-users] Intermittent failure to find font,
 followed by IOError
In-Reply-To: <4AE9A9FE.6040306@chamonix.reportlab.co.uk>
References: <DBA10110A4D98644A505089C2313187103DC63BC@GMTOMB01.globeandmail.net><956003ae0901191437pe94829ctd39af7b19a8bb50c@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6419@GMTOMB01.globeandmail.net>
	<956003ae0901200939g3d13a289ob80296b40e2923cc@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6426@GMTOMB01.globeandmail.net><4976168A.2050406@chamonix.reportlab.co.uk>
	<DBA10110A4D98644A505089C2313187103DC6435@GMTOMB01.globeandmail.net>
	<935E6400826049439C33D7BC3DC930360CEF7F30@GMEXMBS1.globeandmail.net>
	<4AE824C5.5070102@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF7F7D@GMEXMBS1.globeandmail.net>
	<4AE9A9FE.6040306@chamonix.reportlab.co.uk>
Message-ID: <935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>

Hi Robin. Thanks for the patch. It's been applied, and now we get the following:

      File "/usr/lib/python2.5/site-packages/reportlab/pdfbase/pdfmetrics.py", line 79, in parseAFMFile
        lines = open_and_readlines(afmFileName, 'r')

      File "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", line 462, in open_and_readlines
        return open_and_read(name,mode).split('\n')

      File "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", line 459, in open_and_read
        return open_for_read(name,mode).read()

      File "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", line 454, in open_for_read
        dbg.dump()

      File "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", line 810, in dump
        f = open(self.fn,'wb')

    IOError: file() constructor not accessible in restricted mode, while looking for faceName='AGFScalaSansBold'

The faceName matches one which is registered before any other PDF work is done. The IOError is the DebugMemo.dump() failing. I've never seen that error before. Could it be another symptom of the same issue? The original open() for the font could be raising this error. Could it be a side-effect of a mod_python configuration?

FYI, we're running Python 2.5.2 and mod_python 3.3.1. 

Thanks,
Ian. 

> -----Original Message-----
> From: reportlab-users-bounces at lists2.reportlab.com 
> [mailto:reportlab-users-bounces at lists2.reportlab.com] On 
> Behalf Of Robin Becker
> Sent: October 29, 2009 10:43 AM
> To: For users of Reportlab open source software
> Subject: Re: [reportlab-users] Intermittent failure to find 
> font, followed by IOError
> 
> My hack to bruteForceSearchForAFM missed out a comma, here's 
> a better version
> 
> def bruteForceSearchForAFM(faceName):
>      """Looks in all AFM files on path for face with given name.
> 
>      Returns AFM file name or None.  Ouch!"""
>      from reportlab.rl_config import T1SearchPath
> 
>      for dirname in T1SearchPath:
>          if not rl_isdir(dirname): continue
>          possibles = rl_glob(dirname + os.sep + '*.[aA][fF][mM]')
>          for possible in possibles:
>              try:
>                  topDict, glyphDict = parseAFMFile(possible)
>                  if topDict['FontName'] == faceName:
>                      return possible
>              except:
>                  t,v,b=sys.exc_info()
>                  v.args = (' '.join(v.args)+', while looking 
> for faceName=%r' %
> faceName,)
>                  raise
> 
> --
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
> 

From Robert at AbilitySys.com  Wed Nov  4 00:31:13 2009
From: Robert at AbilitySys.com (Robert Young)
Date: Tue, 3 Nov 2009 21:31:13 -0800
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <4AF05FF8.6060503@chamonix.reportlab.co.uk>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>
	<4AF05FF8.6060503@chamonix.reportlab.co.uk>
Message-ID: <387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>


Thanks, that's (almost) exactly what I needed. My current code is
reading in each line, and putting each one out as a separate
"paragraph." Under that sort of arrangement, I want to put out the
header when a paragraph is the first one on a new page.

I think I can rewrite my code to put out all the lines for a group as a
single paragraph, and my test show that the PTOContainer gives me the
header when the paragraph goes over a page boundary, but just for grins,
is there a way to generate a header when a paragraph is the first thing
on a page?

- Robert

-----Original Message-----
From: reportlab-users-bounces at lists2.reportlab.com
[mailto:reportlab-users-bounces at lists2.reportlab.com] On Behalf Of Robin
Becker
Sent: Tuesday, November 03, 2009 8:53 AM
To: For users of Reportlab open source software
Subject: Re: [reportlab-users] Page headings in platypus




Robert Young wrote:



I am trying to write code that will place a "continued" heading on a
> page. I have added all the "paragraphs" to a "story" and once they are
> all added, I use the build method and can place global page headers
with
> no p[problem. However, I want to add a section heading when the data
> flows on to the next page. For example, the data looks like this:
>  

There is a gadget in flowables.py that attempts this sort of thing. It's
called 
PTOContainer and attempts to do injection of specified lists into the
flow when 
it is split. (PTO stands for "Please Turn Over"). Personally I hate it
as it's 
full of edge cases and bugs. For your case I guess you need to do
something like

story.append(PTOContainer([section1flowables],header=[ContinuedSection1F
lowables])

give it a whirl and see what happens.

> 
> Section 1
> 
>   Line 1
> 
>   Line 2
> 
>   Line 3
> 
>   ...
> 
>   Line n
> 
> Section 2
> 
>   Line 1
> 
>   Line 2
> 
>   Line 3
> 
>   ...
> 
>   Line n
> 
>  
> 
> When a section flows on to a new page, I want to add the heading
> "Section 1 (continued)." The problem is, the pagination occurs long
> after the "story" is built, so I have no idea where the break is
> occurring, and I don't really want to hard code a break anyhow.
> 
>  
> 
> How can I detect during the build where a break occurs, and how can I
> determine the appropriate data to print at that time? Is there such an
> attribute as a paragraph header?
> 
>  
.....

-- 
Robin Becker
_______________________________________________
reportlab-users mailing list
reportlab-users at lists2.reportlab.com
http://two.pairlist.net/mailman/listinfo/reportlab-users

From robin at reportlab.com  Wed Nov  4 05:36:43 2009
From: robin at reportlab.com (Robin Becker)
Date: Wed, 04 Nov 2009 10:36:43 +0000
Subject: [reportlab-users] Intermittent failure to find font,
 followed by IOError
In-Reply-To: <935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>
References: <DBA10110A4D98644A505089C2313187103DC63BC@GMTOMB01.globeandmail.net><956003ae0901191437pe94829ctd39af7b19a8bb50c@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6419@GMTOMB01.globeandmail.net>	<956003ae0901200939g3d13a289ob80296b40e2923cc@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6426@GMTOMB01.globeandmail.net><4976168A.2050406@chamonix.reportlab.co.uk>	<DBA10110A4D98644A505089C2313187103DC6435@GMTOMB01.globeandmail.net>	<935E6400826049439C33D7BC3DC930360CEF7F30@GMEXMBS1.globeandmail.net>	<4AE824C5.5070102@chamonix.reportlab.co.uk>	<935E6400826049439C33D7BC3DC930360CEF7F7D@GMEXMBS1.globeandmail.net>	<4AE9A9FE.6040306@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>
Message-ID: <4AF1593B.6030000@chamonix.reportlab.co.uk>

Stevens, Ian wrote:
> Hi Robin. Thanks for the patch. It's been applied, and now we get the following:
> 
>       File "/usr/lib/python2.5/site-packages/reportlab/pdfbase/pdfmetrics.py", line 79, in parseAFMFile
>         lines = open_and_readlines(afmFileName, 'r')
> 
>       File "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", line 462, in open_and_readlines
>         return open_and_read(name,mode).split('\n')
> 
>       File "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", line 459, in open_and_read
>         return open_for_read(name,mode).read()
> 
>       File "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", line 454, in open_for_read
>         dbg.dump()
> 
>       File "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", line 810, in dump
>         f = open(self.fn,'wb')
> 
>     IOError: file() constructor not accessible in restricted mode, while looking for faceName='AGFScalaSansBold'
> 
> The faceName matches one which is registered before any other PDF work is done. The IOError is the DebugMemo.dump() failing. I've never seen that error before. Could it be another symptom of the same issue? The original open() for the font could be raising this error. Could it be a side-effect of a mod_python configuration?
> 
I think you're right; if open (ie alias of file) is not availble in the dump 
then it might well be the problem in the original open.

Googling for the error message "IOError: file() constructor not accessible in 
restricted mode" seems to indicate that it might be related to rexec/mod_python.

This link seems to bear out my opinion that Python restricted mode ought to be 
considered useless

http://www.dalkescientific.com/writings/diary/archive/2008/03/03/restricted_python.html

this email

http://www.modpython.org/pipermail/mod_python/2004-April/015476.html

seems to imply this has been seen in mod_python land before. I think the 
implication of the latter is that code is being executed in the wrong thread. I 
will try asking about this on clp.



> FYI, we're running Python 2.5.2 and mod_python 3.3.1. 
> 
> Thanks,
> Ian. 
> 
>.......
-- 
Robin Becker

From robin at reportlab.com  Wed Nov  4 07:29:25 2009
From: robin at reportlab.com (Robin Becker)
Date: Wed, 04 Nov 2009 12:29:25 +0000
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>	<4AF05FF8.6060503@chamonix.reportlab.co.uk>
	<387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>
Message-ID: <4AF173A5.5050705@chamonix.reportlab.co.uk>

Robert Young wrote:
> Thanks, that's (almost) exactly what I needed. My current code is
> reading in each line, and putting each one out as a separate
> "paragraph." Under that sort of arrangement, I want to put out the
> header when a paragraph is the first one on a new page.
> 
> I think I can rewrite my code to put out all the lines for a group as a
> single paragraph, and my test show that the PTOContainer gives me the
> header when the paragraph goes over a page boundary, but just for grins,
> is there a way to generate a header when a paragraph is the first thing
> on a page?
> 
> - Robert
........

In latest reportlab there are new Programming Flowables which allow condifitonal 
execution based on the state of the current doctemplate and frame etc etc.

I think you should be able to use something like

DocIf('string boolean expression',[thenflowables],[elseflowables])

ie


story.append(DocIf('doc.frame.atTop',[Paragraph('sectionhead...',style=headingStyle)]))

prior to your lead paragraph for each section.
-- 
Robin Becker

From Robert at AbilitySys.com  Wed Nov  4 08:48:00 2009
From: Robert at AbilitySys.com (Robert Young)
Date: Wed, 4 Nov 2009 05:48:00 -0800
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <4AF173A5.5050705@chamonix.reportlab.co.uk>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>	<4AF05FF8.6060503@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>
	<4AF173A5.5050705@chamonix.reportlab.co.uk>
Message-ID: <387B7630D8F908498B9F02EE181EDB290A9536@ability-ntn.AbilitySys.local>

That sounds like *exactly* what I want!!! How do I "import" the DocIf
function? (i.e., I get an error with " from reportlab.platypus import
DocIf")

- Robert 

-----Original Message-----
From: reportlab-users-bounces at lists2.reportlab.com
[mailto:reportlab-users-bounces at lists2.reportlab.com] On Behalf Of Robin
Becker
Sent: Wednesday, November 04, 2009 4:29 AM
To: For users of Reportlab open source software
Subject: Re: [reportlab-users] Page headings in platypus

Robert Young wrote:
> Thanks, that's (almost) exactly what I needed. My current code is
> reading in each line, and putting each one out as a separate
> "paragraph." Under that sort of arrangement, I want to put out the
> header when a paragraph is the first one on a new page.
> 
> I think I can rewrite my code to put out all the lines for a group as
a
> single paragraph, and my test show that the PTOContainer gives me the
> header when the paragraph goes over a page boundary, but just for
grins,
> is there a way to generate a header when a paragraph is the first
thing
> on a page?
> 
> - Robert
........

In latest reportlab there are new Programming Flowables which allow
condifitonal 
execution based on the state of the current doctemplate and frame etc
etc.

I think you should be able to use something like

DocIf('string boolean expression',[thenflowables],[elseflowables])

ie


story.append(DocIf('doc.frame.atTop',[Paragraph('sectionhead...',style=h
eadingStyle)]))

prior to your lead paragraph for each section.
-- 
Robin Becker
_______________________________________________
reportlab-users mailing list
reportlab-users at lists2.reportlab.com
http://two.pairlist.net/mailman/listinfo/reportlab-users

From Robert at AbilitySys.com  Wed Nov  4 09:42:33 2009
From: Robert at AbilitySys.com (Robert Young)
Date: Wed, 4 Nov 2009 06:42:33 -0800
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <4AF173A5.5050705@chamonix.reportlab.co.uk>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>	<4AF05FF8.6060503@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>
	<4AF173A5.5050705@chamonix.reportlab.co.uk>
Message-ID: <387B7630D8F908498B9F02EE181EDB290A9537@ability-ntn.AbilitySys.local>


Actually, scratch my earlier note. I found that:

from reportlab.platypus.flowables import DocIf

However, with the statement:

story.append(DocIf('doc.frame.atTop',headertext))

gets me an error:

AttributeError: atTop
docEval doc.frame.atTop failed!

Ideas?

- Robert



-----Original Message-----
From: reportlab-users-bounces at lists2.reportlab.com
[mailto:reportlab-users-bounces at lists2.reportlab.com] On Behalf Of Robin
Becker
Sent: Wednesday, November 04, 2009 4:29 AM
To: For users of Reportlab open source software
Subject: Re: [reportlab-users] Page headings in platypus

Robert Young wrote:
> Thanks, that's (almost) exactly what I needed. My current code is
> reading in each line, and putting each one out as a separate
> "paragraph." Under that sort of arrangement, I want to put out the
> header when a paragraph is the first one on a new page.
> 
> I think I can rewrite my code to put out all the lines for a group as
a
> single paragraph, and my test show that the PTOContainer gives me the
> header when the paragraph goes over a page boundary, but just for
grins,
> is there a way to generate a header when a paragraph is the first
thing
> on a page?
> 
> - Robert
........

In latest reportlab there are new Programming Flowables which allow
condifitonal 
execution based on the state of the current doctemplate and frame etc
etc.

I think you should be able to use something like

DocIf('string boolean expression',[thenflowables],[elseflowables])

ie


story.append(DocIf('doc.frame.atTop',[Paragraph('sectionhead...',style=h
eadingStyle)]))

prior to your lead paragraph for each section.
-- 
Robin Becker
_______________________________________________
reportlab-users mailing list
reportlab-users at lists2.reportlab.com
http://two.pairlist.net/mailman/listinfo/reportlab-users

From robin at reportlab.com  Wed Nov  4 10:52:48 2009
From: robin at reportlab.com (Robin Becker)
Date: Wed, 04 Nov 2009 15:52:48 +0000
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <387B7630D8F908498B9F02EE181EDB290A9537@ability-ntn.AbilitySys.local>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>	<4AF05FF8.6060503@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>	<4AF173A5.5050705@chamonix.reportlab.co.uk>
	<387B7630D8F908498B9F02EE181EDB290A9537@ability-ntn.AbilitySys.local>
Message-ID: <4AF1A350.3000900@chamonix.reportlab.co.uk>

Robert Young wrote:
> Actually, scratch my earlier note. I found that:
> 
> from reportlab.platypus.flowables import DocIf
> 
> However, with the statement:
> 
> story.append(DocIf('doc.frame.atTop',headertext))
> 
> gets me an error:
> 
> AttributeError: atTop
> docEval doc.frame.atTop failed!
> 
> Ideas?
> 
> - Robert

Doh! not enough doughnuts today. Frame objects have an _atTop attribute.

> Robert Young wrote:
>> Thanks, that's (almost) exactly what I needed. My current code is
>> reading in each line, and putting each one out as a separate
>> "paragraph." Under that sort of arrangement, I want to put out the
..........
-- 
Robin Becker

From IStevens at globeandmail.com  Wed Nov  4 14:10:01 2009
From: IStevens at globeandmail.com (Stevens, Ian)
Date: Wed, 4 Nov 2009 14:10:01 -0500
Subject: [reportlab-users] Intermittent failure to find font,
 followed by IOError
In-Reply-To: <4AF1593B.6030000@chamonix.reportlab.co.uk>
References: <DBA10110A4D98644A505089C2313187103DC63BC@GMTOMB01.globeandmail.net><956003ae0901191437pe94829ctd39af7b19a8bb50c@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6419@GMTOMB01.globeandmail.net>
	<956003ae0901200939g3d13a289ob80296b40e2923cc@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6426@GMTOMB01.globeandmail.net><4976168A.2050406@chamonix.reportlab.co.uk>
	<DBA10110A4D98644A505089C2313187103DC6435@GMTOMB01.globeandmail.net>
	<935E6400826049439C33D7BC3DC930360CEF7F30@GMEXMBS1.globeandmail.net>
	<4AE824C5.5070102@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF7F7D@GMEXMBS1.globeandmail.net>
	<4AE9A9FE.6040306@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>
	<4AF1593B.6030000@chamonix.reportlab.co.uk>
Message-ID: <935E6400826049439C33D7BC3DC930360CEF80E2@GMEXMBS1.globeandmail.net>

Thanks Robin. This link may shed some light: 

http://www.modpython.org/live/current/doc-html/pyapi-interps.html 

Specifically,

"Note that if any third party module is being used which has a C code component that uses the simplified API for access to the Global Interpreter Lock (GIL) for Python extension modules, then the interpreter name must be forcibly set to be 'main_interpreter'. This is necessary as such a module will only work correctly if run within the context of the first Python interpreter created by the process. If not forced to run under the 'main_interpreter', a range of Python errors can arise, each typically referring to code being run in restricted mode."

Also:

"Default behaviour is to name interpreters using the Apache virtual server name (ServerName directive). This means that all scripts in the same virtual server execute in the same subinterpreter, but scripts in different virtual servers execute in different subinterpreters with completely separate namespaces."

We are using the same codebase for several different domain names. I suppose it is possible that some objects are being shared across domains, and subsequently over interpreters as well. It might be a coincidence, but over 95% of the URLs which generate these errors are on the same subdomain even though they account for nowhere near 95% of the traffic. 

Ian.

> -----Original Message-----
> From: reportlab-users-bounces at lists2.reportlab.com 
> [mailto:reportlab-users-bounces at lists2.reportlab.com] On 
> Behalf Of Robin Becker
> Sent: November 4, 2009 5:37 AM
> To: For users of Reportlab open source software
> Subject: Re: [reportlab-users] Intermittent failure to find 
> font, followed by IOError
> 
> Stevens, Ian wrote:
> > Hi Robin. Thanks for the patch. It's been applied, and now 
> we get the following:
> > 
> >       File 
> "/usr/lib/python2.5/site-packages/reportlab/pdfbase/pdfmetrics
> .py", line 79, in parseAFMFile
> >         lines = open_and_readlines(afmFileName, 'r')
> > 
> >       File 
> "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", 
> line 462, in open_and_readlines
> >         return open_and_read(name,mode).split('\n')
> > 
> >       File 
> "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", 
> line 459, in open_and_read
> >         return open_for_read(name,mode).read()
> > 
> >       File 
> "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", 
> line 454, in open_for_read
> >         dbg.dump()
> > 
> >       File 
> "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py", 
> line 810, in dump
> >         f = open(self.fn,'wb')
> > 
> >     IOError: file() constructor not accessible in 
> restricted mode, while looking for faceName='AGFScalaSansBold'
> > 
> > The faceName matches one which is registered before any 
> other PDF work is done. The IOError is the DebugMemo.dump() 
> failing. I've never seen that error before. Could it be 
> another symptom of the same issue? The original open() for 
> the font could be raising this error. Could it be a 
> side-effect of a mod_python configuration?
> > 
> I think you're right; if open (ie alias of file) is not 
> availble in the dump then it might well be the problem in the 
> original open.
> 
> Googling for the error message "IOError: file() constructor 
> not accessible in restricted mode" seems to indicate that it 
> might be related to rexec/mod_python.
> 
> This link seems to bear out my opinion that Python restricted 
> mode ought to be considered useless
> 
> http://www.dalkescientific.com/writings/diary/archive/2008/03/
> 03/restricted_python.html
> 
> this email
> 
> http://www.modpython.org/pipermail/mod_python/2004-April/015476.html
> 
> seems to imply this has been seen in mod_python land before. 
> I think the implication of the latter is that code is being 
> executed in the wrong thread. I will try asking about this on clp.
> 
> 
> 
> > FYI, we're running Python 2.5.2 and mod_python 3.3.1. 
> > 
> > Thanks,
> > Ian. 
> > 
> >.......
> --
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
> 

From IStevens at globeandmail.com  Wed Nov  4 14:17:55 2009
From: IStevens at globeandmail.com (Stevens, Ian)
Date: Wed, 4 Nov 2009 14:17:55 -0500
Subject: [reportlab-users] Intermittent failure to find font,
 followed by IOError
References: <DBA10110A4D98644A505089C2313187103DC63BC@GMTOMB01.globeandmail.net><956003ae0901191437pe94829ctd39af7b19a8bb50c@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6419@GMTOMB01.globeandmail.net>
	<956003ae0901200939g3d13a289ob80296b40e2923cc@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6426@GMTOMB01.globeandmail.net><4976168A.2050406@chamonix.reportlab.co.uk>
	<DBA10110A4D98644A505089C2313187103DC6435@GMTOMB01.globeandmail.net>
	<935E6400826049439C33D7BC3DC930360CEF7F30@GMEXMBS1.globeandmail.net>
	<4AE824C5.5070102@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF7F7D@GMEXMBS1.globeandmail.net>
	<4AE9A9FE.6040306@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>
	<4AF1593B.6030000@chamonix.reportlab.co.uk> 
Message-ID: <935E6400826049439C33D7BC3DC930360CEF80E4@GMEXMBS1.globeandmail.net>

I'll see if I can replicate this by creating two Apache sites, each with a different ServerName, and hitting them both. If so, I'll set the same PythonInterpreter for both and see if the error goes away. It's a long-shot, but it's a quick enough test.

Ian.

> -----Original Message-----
> From: Stevens, Ian 
> Sent: November 4, 2009 2:10 PM
> To: 'For users of Reportlab open source software'
> Subject: RE: [reportlab-users] Intermittent failure to find 
> font, followed by IOError
> 
> Thanks Robin. This link may shed some light: 
> 
> http://www.modpython.org/live/current/doc-html/pyapi-interps.html 
> 
> Specifically,
> 
> "Note that if any third party module is being used which has 
> a C code component that uses the simplified API for access to 
> the Global Interpreter Lock (GIL) for Python extension 
> modules, then the interpreter name must be forcibly set to be 
> 'main_interpreter'. This is necessary as such a module will 
> only work correctly if run within the context of the first 
> Python interpreter created by the process. If not forced to 
> run under the 'main_interpreter', a range of Python errors 
> can arise, each typically referring to code being run in 
> restricted mode."
> 
> Also:
> 
> "Default behaviour is to name interpreters using the Apache 
> virtual server name (ServerName directive). This means that 
> all scripts in the same virtual server execute in the same 
> subinterpreter, but scripts in different virtual servers 
> execute in different subinterpreters with completely separate 
> namespaces."
> 
> We are using the same codebase for several different domain 
> names. I suppose it is possible that some objects are being 
> shared across domains, and subsequently over interpreters as 
> well. It might be a coincidence, but over 95% of the URLs 
> which generate these errors are on the same subdomain even 
> though they account for nowhere near 95% of the traffic. 
> 
> Ian.
> 
> > -----Original Message-----
> > From: reportlab-users-bounces at lists2.reportlab.com
> > [mailto:reportlab-users-bounces at lists2.reportlab.com] On Behalf Of 
> > Robin Becker
> > Sent: November 4, 2009 5:37 AM
> > To: For users of Reportlab open source software
> > Subject: Re: [reportlab-users] Intermittent failure to find font, 
> > followed by IOError
> > 
> > Stevens, Ian wrote:
> > > Hi Robin. Thanks for the patch. It's been applied, and now
> > we get the following:
> > > 
> > >       File
> > "/usr/lib/python2.5/site-packages/reportlab/pdfbase/pdfmetrics
> > .py", line 79, in parseAFMFile
> > >         lines = open_and_readlines(afmFileName, 'r')
> > > 
> > >       File
> > "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py",
> > line 462, in open_and_readlines
> > >         return open_and_read(name,mode).split('\n')
> > > 
> > >       File
> > "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py",
> > line 459, in open_and_read
> > >         return open_for_read(name,mode).read()
> > > 
> > >       File
> > "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py",
> > line 454, in open_for_read
> > >         dbg.dump()
> > > 
> > >       File
> > "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py",
> > line 810, in dump
> > >         f = open(self.fn,'wb')
> > > 
> > >     IOError: file() constructor not accessible in
> > restricted mode, while looking for faceName='AGFScalaSansBold'
> > > 
> > > The faceName matches one which is registered before any
> > other PDF work is done. The IOError is the DebugMemo.dump() 
> failing. 
> > I've never seen that error before. Could it be another 
> symptom of the 
> > same issue? The original open() for the font could be raising this 
> > error. Could it be a side-effect of a mod_python configuration?
> > > 
> > I think you're right; if open (ie alias of file) is not availble in 
> > the dump then it might well be the problem in the original open.
> > 
> > Googling for the error message "IOError: file() constructor not 
> > accessible in restricted mode" seems to indicate that it might be 
> > related to rexec/mod_python.
> > 
> > This link seems to bear out my opinion that Python restricted mode 
> > ought to be considered useless
> > 
> > http://www.dalkescientific.com/writings/diary/archive/2008/03/
> > 03/restricted_python.html
> > 
> > this email
> > 
> > http://www.modpython.org/pipermail/mod_python/2004-April/015476.html
> > 
> > seems to imply this has been seen in mod_python land before. 
> > I think the implication of the latter is that code is being 
> executed 
> > in the wrong thread. I will try asking about this on clp.
> > 
> > 
> > 
> > > FYI, we're running Python 2.5.2 and mod_python 3.3.1. 
> > > 
> > > Thanks,
> > > Ian. 
> > > 
> > >.......
> > --
> > Robin Becker
> > _______________________________________________
> > reportlab-users mailing list
> > reportlab-users at lists2.reportlab.com
> > http://two.pairlist.net/mailman/listinfo/reportlab-users
> > 

From carl at personnelware.com  Wed Nov  4 14:48:00 2009
From: carl at personnelware.com (Carl Karsten)
Date: Wed, 4 Nov 2009 13:48:00 -0600
Subject: [reportlab-users] Intermittent failure to find font,
	followed by 	IOError
In-Reply-To: <935E6400826049439C33D7BC3DC930360CEF80E2@GMEXMBS1.globeandmail.net>
References: <DBA10110A4D98644A505089C2313187103DC63BC@GMTOMB01.globeandmail.net>
	<4976168A.2050406@chamonix.reportlab.co.uk>
	<DBA10110A4D98644A505089C2313187103DC6435@GMTOMB01.globeandmail.net>
	<935E6400826049439C33D7BC3DC930360CEF7F30@GMEXMBS1.globeandmail.net>
	<4AE824C5.5070102@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF7F7D@GMEXMBS1.globeandmail.net>
	<4AE9A9FE.6040306@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>
	<4AF1593B.6030000@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80E2@GMEXMBS1.globeandmail.net>
Message-ID: <549053140911041148p5a2c3a53r30b7434a11233c7a@mail.gmail.com>

Anytime someone gets close to this subject I point them to:
"David Beazley: mind-blowing presentation about how the Python GIL
actually works and why it's even worse than most people even imagine."

http://blip.tv/file/2232410

On Wed, Nov 4, 2009 at 1:10 PM, Stevens, Ian <IStevens at globeandmail.com> wrote:
> Thanks Robin. This link may shed some light:
>
> http://www.modpython.org/live/current/doc-html/pyapi-interps.html
>
> Specifically,
>
> "Note that if any third party module is being used which has a C code component that uses the simplified API for access to the Global Interpreter Lock (GIL) for Python extension modules, then the interpreter name must be forcibly set to be 'main_interpreter'. This is necessary as such a module will only work correctly if run within the context of the first Python interpreter created by the process. If not forced to run under the 'main_interpreter', a range of Python errors can arise, each typically referring to code being run in restricted mode."
>
> Also:
>
> "Default behaviour is to name interpreters using the Apache virtual server name (ServerName directive). This means that all scripts in the same virtual server execute in the same subinterpreter, but scripts in different virtual servers execute in different subinterpreters with completely separate namespaces."
>
> We are using the same codebase for several different domain names. I suppose it is possible that some objects are being shared across domains, and subsequently over interpreters as well. It might be a coincidence, but over 95% of the URLs which generate these errors are on the same subdomain even though they account for nowhere near 95% of the traffic.
>
> Ian.
>
>> -----Original Message-----
>> From: reportlab-users-bounces at lists2.reportlab.com
>> [mailto:reportlab-users-bounces at lists2.reportlab.com] On
>> Behalf Of Robin Becker
>> Sent: November 4, 2009 5:37 AM
>> To: For users of Reportlab open source software
>> Subject: Re: [reportlab-users] Intermittent failure to find
>> font, followed by IOError
>>
>> Stevens, Ian wrote:
>> > Hi Robin. Thanks for the patch. It's been applied, and now
>> we get the following:
>> >
>> > ? ? ? File
>> "/usr/lib/python2.5/site-packages/reportlab/pdfbase/pdfmetrics
>> .py", line 79, in parseAFMFile
>> > ? ? ? ? lines = open_and_readlines(afmFileName, 'r')
>> >
>> > ? ? ? File
>> "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py",
>> line 462, in open_and_readlines
>> > ? ? ? ? return open_and_read(name,mode).split('\n')
>> >
>> > ? ? ? File
>> "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py",
>> line 459, in open_and_read
>> > ? ? ? ? return open_for_read(name,mode).read()
>> >
>> > ? ? ? File
>> "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py",
>> line 454, in open_for_read
>> > ? ? ? ? dbg.dump()
>> >
>> > ? ? ? File
>> "/usr/lib/python2.5/site-packages/reportlab/lib/utils.py",
>> line 810, in dump
>> > ? ? ? ? f = open(self.fn,'wb')
>> >
>> > ? ? IOError: file() constructor not accessible in
>> restricted mode, while looking for faceName='AGFScalaSansBold'
>> >
>> > The faceName matches one which is registered before any
>> other PDF work is done. The IOError is the DebugMemo.dump()
>> failing. I've never seen that error before. Could it be
>> another symptom of the same issue? The original open() for
>> the font could be raising this error. Could it be a
>> side-effect of a mod_python configuration?
>> >
>> I think you're right; if open (ie alias of file) is not
>> availble in the dump then it might well be the problem in the
>> original open.
>>
>> Googling for the error message "IOError: file() constructor
>> not accessible in restricted mode" seems to indicate that it
>> might be related to rexec/mod_python.
>>
>> This link seems to bear out my opinion that Python restricted
>> mode ought to be considered useless
>>
>> http://www.dalkescientific.com/writings/diary/archive/2008/03/
>> 03/restricted_python.html
>>
>> this email
>>
>> http://www.modpython.org/pipermail/mod_python/2004-April/015476.html
>>
>> seems to imply this has been seen in mod_python land before.
>> I think the implication of the latter is that code is being
>> executed in the wrong thread. I will try asking about this on clp.
>>
>>
>>
>> > FYI, we're running Python 2.5.2 and mod_python 3.3.1.
>> >
>> > Thanks,
>> > Ian.
>> >
>> >.......
>> --
>> Robin Becker
>> _______________________________________________
>> reportlab-users mailing list
>> reportlab-users at lists2.reportlab.com
>> http://two.pairlist.net/mailman/listinfo/reportlab-users
>>
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>
>



-- 
Carl K

From IStevens at globeandmail.com  Wed Nov  4 19:18:09 2009
From: IStevens at globeandmail.com (Stevens, Ian)
Date: Wed, 4 Nov 2009 19:18:09 -0500
Subject: [reportlab-users] Intermittent failure to find font,
 followed by IOError
In-Reply-To: <935E6400826049439C33D7BC3DC930360CEF80E4@GMEXMBS1.globeandmail.net>
References: <DBA10110A4D98644A505089C2313187103DC63BC@GMTOMB01.globeandmail.net><956003ae0901191437pe94829ctd39af7b19a8bb50c@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6419@GMTOMB01.globeandmail.net>
	<956003ae0901200939g3d13a289ob80296b40e2923cc@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6426@GMTOMB01.globeandmail.net><4976168A.2050406@chamonix.reportlab.co.uk>
	<DBA10110A4D98644A505089C2313187103DC6435@GMTOMB01.globeandmail.net>
	<935E6400826049439C33D7BC3DC930360CEF7F30@GMEXMBS1.globeandmail.net>
	<4AE824C5.5070102@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF7F7D@GMEXMBS1.globeandmail.net>
	<4AE9A9FE.6040306@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>
	<4AF1593B.6030000@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80E4@GMEXMBS1.globeandmail.net>
Message-ID: <935E6400826049439C33D7BC3DC930360CEF80F8@GMEXMBS1.globeandmail.net>

> > We are using the same codebase for several different domain 
> > names. I suppose it is possible that some objects are being shared across 
> > domains, and subsequently over interpreters as well. It might be a 

Right, so here's what I've done so far:

I set up two Apache virtual hosts using different ServerNames. Starting with apache-mpm-worker (as on production), I hit random URLs, 50% with one ServerName, 50% with the other. The error appeared, along with some previously-unseen KeyErrors when changing fonts. (Those are probably the result of the _reset which I added when I assumed production was running prefork.)

The errors ceased when I switched to prefork, changing nothing else. This was odd as changing to prefork on production would cause the errors to become more frequent. I then turned on caching to see if sharing objects between interpreters would (somehow) cause the error to appear. Still nothing. Very odd, but as expected.

Switching back to apache-mpm-worker, I changed my sites to use the same PythonInterpreter (see http://www.modpython.org/live/current/doc-html/dir-other-pi.html). As would be expected, the errors increased dramatically, probably because of the combination of fewer interpreters, and _reset being called in a multi-threaded environment.

Using the same PythonInterpreter and apache-mpm-prefork had no negative effect.

I'm still uncertain as to why our production environment raises more IOErrors for fonts under prefork than worker, and why I can't replicate it using this technique. It's positive that I was able to replicate the error with the knowledge that each ServerName setting results in a different PythonInterpreter.

Ian.


From Robert at AbilitySys.com  Wed Nov  4 21:17:44 2009
From: Robert at AbilitySys.com (Robert Young)
Date: Wed, 4 Nov 2009 18:17:44 -0800
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <4AF1A350.3000900@chamonix.reportlab.co.uk>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>	<4AF05FF8.6060503@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>	<4AF173A5.5050705@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9537@ability-ntn.AbilitySys.local>
	<4AF1A350.3000900@chamonix.reportlab.co.uk>
Message-ID: <387B7630D8F908498B9F02EE181EDB290A9539@ability-ntn.AbilitySys.local>


Thanks - that stopped the crash, but it doesn't actually put headers in
my report. 

The code now does:

story.append(Paragraph(Group1header1,headerstyle))
story.append(DocIf('doc.frame._atTop',Paragraph(continuation1,headerstyl
e)))
story.append(Paragraph(detail line1,detailstyle))
story.append(Paragraph(detail line2,detailstyle))
story.append(Paragraph(detail line3,detailstyle)) 
...
story.append(Paragraph(detail line_n,detailstyle)) 

story.append(Paragraph(Group2header1,headerstyle))
story.append(DocIf('doc.frame._atTop',Paragraph(continuation2,headerstyl
e)))
story.append(Paragraph(detail line1,detailstyle))
story.append(Paragraph(detail line2,detailstyle))
story.append(Paragraph(detail line3,detailstyle)) 
...
story.append(Paragraph(detail line_n,detailstyle))

and so on. Then it does the build:

pdf.build(story, onFirstPage=BuildPage,onLaterPages=BuildPage)

(with BuildPage putting page numbers on each page.

Each detail line paragraph is only one or two lines, so it is rare that
a paragraph will break across a page. I was hoping that each "DocIf"
would put the appropriate continuation header when any of the following
detail lines is at the start of a page. Or is there some sort of
container between "paragraph" and "story" that would be better to use?

- Robert


-----Original Message-----
From: reportlab-users-bounces at lists2.reportlab.com
[mailto:reportlab-users-bounces at lists2.reportlab.com] On Behalf Of Robin
Becker
Sent: Wednesday, November 04, 2009 7:53 AM
To: For users of Reportlab open source software
Subject: Re: [reportlab-users] Page headings in platypus

Robert Young wrote:
> Actually, scratch my earlier note. I found that:
> 
> from reportlab.platypus.flowables import DocIf
> 
> However, with the statement:
> 
> story.append(DocIf('doc.frame.atTop',headertext))
> 
> gets me an error:
> 
> AttributeError: atTop
> docEval doc.frame.atTop failed!
> 
> Ideas?
> 
> - Robert

Doh! not enough doughnuts today. Frame objects have an _atTop attribute.

> Robert Young wrote:
>> Thanks, that's (almost) exactly what I needed. My current code is
>> reading in each line, and putting each one out as a separate
>> "paragraph." Under that sort of arrangement, I want to put out the
..........
-- 
Robin Becker
_______________________________________________
reportlab-users mailing list
reportlab-users at lists2.reportlab.com
http://two.pairlist.net/mailman/listinfo/reportlab-users

From robin at reportlab.com  Thu Nov  5 05:42:34 2009
From: robin at reportlab.com (Robin Becker)
Date: Thu, 05 Nov 2009 10:42:34 +0000
Subject: [reportlab-users] Intermittent failure to find font,
 followed by IOError
In-Reply-To: <935E6400826049439C33D7BC3DC930360CEF80F8@GMEXMBS1.globeandmail.net>
References: <DBA10110A4D98644A505089C2313187103DC63BC@GMTOMB01.globeandmail.net><956003ae0901191437pe94829ctd39af7b19a8bb50c@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6419@GMTOMB01.globeandmail.net>	<956003ae0901200939g3d13a289ob80296b40e2923cc@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6426@GMTOMB01.globeandmail.net><4976168A.2050406@chamonix.reportlab.co.uk>	<DBA10110A4D98644A505089C2313187103DC6435@GMTOMB01.globeandmail.net>	<935E6400826049439C33D7BC3DC930360CEF7F30@GMEXMBS1.globeandmail.net>	<4AE824C5.5070102@chamonix.reportlab.co.uk>	<935E6400826049439C33D7BC3DC930360CEF7F7D@GMEXMBS1.globeandmail.net>	<4AE9A9FE.6040306@chamonix.reportlab.co.uk>	<935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>	<4AF1593B.6030000@chamonix.reportlab.co.uk>	<935E6400826049439C33D7BC3DC930360CEF80E4@GMEXMBS1.globeandmail.net>
	<935E6400826049439C33D7BC3DC930360CEF80F8@GMEXMBS1.globeandmail.net>
Message-ID: <4AF2AC1A.6010402@chamonix.reportlab.co.uk>

Stevens, Ian wrote:
......

Python guru Martin v. Loewis says this

> Restricted mode is still available, and activated whenever
> a frame's builtins directory is different from the interpreter's;
> see PyFrame_IsRestricted.

so if your requests are somehow being passed around to different interpreters 
that would cause this.
-- 
Robin Becker

From paul.barrass at safeonlinebilling.com  Thu Nov  5 09:46:26 2009
From: paul.barrass at safeonlinebilling.com (Paul Barrass)
Date: Thu, 05 Nov 2009 14:46:26 +0000
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <387B7630D8F908498B9F02EE181EDB290A9539@ability-ntn.AbilitySys.local>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>	<4AF05FF8.6060503@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>	<4AF173A5.5050705@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9537@ability-ntn.AbilitySys.local>	<4AF1A350.3000900@chamonix.reportlab.co.uk>
	<387B7630D8F908498B9F02EE181EDB290A9539@ability-ntn.AbilitySys.local>
Message-ID: <4AF2E542.5030700@safeonlinebilling.com>

Robert Young wrote:
> Each detail line paragraph is only one or two lines, so it is rare that
> a paragraph will break across a page. I was hoping that each "DocIf"
> would put the appropriate continuation header when any of the following
> detail lines is at the start of a page. Or is there some sort of
> container between "paragraph" and "story" that would be better to use?
>
>   
I think the PTOContainer Robin mentioned earlier is the best tool for 
that particular task - the DocIfs were to answer your follow-up question 
regarding conditional headers - I guess they could work well with 
CondPageBreaks.  If you wanted to use DocIfs for '...continued' headers, 
I think you'd need to insert one everywhere a page break could happen - 
though this wouldn't work unless you forced Paragraphs not to be split 
over pages.  I've never used the conditional elements though, so there 
could be subtleties I've not noticed.

Paul Barrass.

From Robert at AbilitySys.com  Thu Nov  5 11:16:10 2009
From: Robert at AbilitySys.com (Robert Young)
Date: Thu, 5 Nov 2009 08:16:10 -0800
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <4AF2E542.5030700@safeonlinebilling.com>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>	<4AF05FF8.6060503@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>	<4AF173A5.5050705@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9537@ability-ntn.AbilitySys.local>	<4AF1A350.3000900@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9539@ability-ntn.AbilitySys.local>
	<4AF2E542.5030700@safeonlinebilling.com>
Message-ID: <387B7630D8F908498B9F02EE181EDB290A953C@ability-ntn.AbilitySys.local>


Yes, when I did the change for that container it worked as expected,
probably better than what I described as desired below, since there
would always be the edge condition that the new "group" would start on a
page, making me take unusual steps to avoid the "header" followed
immediately by "header continued" on the same page.

My problem with PTO was that the example gives was a single paragraph,
which means I lost the hanging indents and line breaks in my text. I'll
have to experiment with using a PTO container  that has multiple
paragraphs.

- Robert

-----Original Message-----
From: reportlab-users-bounces at lists2.reportlab.com
[mailto:reportlab-users-bounces at lists2.reportlab.com] On Behalf Of Paul
Barrass
Sent: Thursday, November 05, 2009 6:46 AM
To: For users of Reportlab open source software
Subject: Re: [reportlab-users] Page headings in platypus

Robert Young wrote:
> Each detail line paragraph is only one or two lines, so it is rare
that
> a paragraph will break across a page. I was hoping that each "DocIf"
> would put the appropriate continuation header when any of the
following
> detail lines is at the start of a page. Or is there some sort of
> container between "paragraph" and "story" that would be better to use?
>
>   
I think the PTOContainer Robin mentioned earlier is the best tool for 
that particular task - the DocIfs were to answer your follow-up question

regarding conditional headers - I guess they could work well with 
CondPageBreaks.  If you wanted to use DocIfs for '...continued' headers,

I think you'd need to insert one everywhere a page break could happen - 
though this wouldn't work unless you forced Paragraphs not to be split 
over pages.  I've never used the conditional elements though, so there 
could be subtleties I've not noticed.

Paul Barrass.
_______________________________________________
reportlab-users mailing list
reportlab-users at lists2.reportlab.com
http://two.pairlist.net/mailman/listinfo/reportlab-users

From paul.barrass at safeonlinebilling.com  Thu Nov  5 11:47:48 2009
From: paul.barrass at safeonlinebilling.com (Paul Barrass)
Date: Thu, 05 Nov 2009 16:47:48 +0000
Subject: [reportlab-users] Page headings in platypus
In-Reply-To: <387B7630D8F908498B9F02EE181EDB290A953C@ability-ntn.AbilitySys.local>
References: <387B7630D8F908498B9F02EE181EDB290A952D@ability-ntn.AbilitySys.local>	<4AF05FF8.6060503@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9534@ability-ntn.AbilitySys.local>	<4AF173A5.5050705@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9537@ability-ntn.AbilitySys.local>	<4AF1A350.3000900@chamonix.reportlab.co.uk><387B7630D8F908498B9F02EE181EDB290A9539@ability-ntn.AbilitySys.local>	<4AF2E542.5030700@safeonlinebilling.com>
	<387B7630D8F908498B9F02EE181EDB290A953C@ability-ntn.AbilitySys.local>
Message-ID: <4AF301B4.3020004@safeonlinebilling.com>

Robert Young wrote:
> My problem with PTO was that the example gives was a single paragraph,
> which means I lost the hanging indents and line breaks in my text. I'll
> have to experiment with using a PTO container  that has multiple
> paragraphs.
>   

Simple pass a list of Paragraphs/whatever to PTOContainer, that will 
then take care of headers/footers on each Frame.

Paul Barrass.

From sorin.sbarnea at gmail.com  Thu Nov  5 12:08:20 2009
From: sorin.sbarnea at gmail.com (Sorin Sbarnea)
Date: Thu, 5 Nov 2009 19:08:20 +0200
Subject: [reportlab-users] reportlab fail installing on Windows 7 x64 with
	Python 2.6 x64 (easy_install)
Message-ID: <d77cce480911050908j6711cbe3qaa598b46b4ff790@mail.gmail.com>

I remarked that easy_install reportlab fails with below errror on
Windows 7 x64 with Python 2.6 x64:
Searching for reportlab
Reading http://pypi.python.org/simple/reportlab/
Reading http://www.reportlab.com/
Best match: reportLab 2.3
Downloading http://pypi.python.org/packages/source/r/reportlab/reportLab-2.3.zip#md5=7d98b26fa287a9e4be4d35d682ce64ac
Processing reportLab-2.3.zip
Running ReportLab_2_3\setup.py -q bdist_egg --dist-dir
c:\temp\easy_install-naj8bw\ReportLab_2_3\egg-dist-tmp-hwrzoo
_rl_accel.c
c:\temp\easy_install-naj8bw\ReportLab_2_3\src\rl_addons\rl_accel\_rl_accel.c(136)
: warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible
loss of data
c:\temp\easy_install-naj8bw\ReportLab_2_3\src\rl_addons\rl_accel\_rl_accel.c(433)
: warning C4244: '=' : conversion from '__int64' to 'unsigned int',
possible loss of data
c:\temp\easy_install-naj8bw\ReportLab_2_3\src\rl_addons\rl_accel\_rl_accel.c(512)
: warning C4267: '=' : conversion from 'size_t' to 'int', possible
loss of data
c:\temp\easy_install-naj8bw\ReportLab_2_3\src\rl_addons\rl_accel\_rl_accel.c(536)
: warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible
loss of data
c:\temp\easy_install-naj8bw\ReportLab_2_3\src\rl_addons\rl_accel\_rl_accel.c(539)
: warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible
loss of data
c:\temp\easy_install-naj8bw\ReportLab_2_3\src\rl_addons\rl_accel\_rl_accel.c(1177)
: warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible
loss of data
c:\temp\easy_install-naj8bw\ReportLab_2_3\src\rl_addons\rl_accel\_rl_accel.c(1199)
: warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible
loss of data
c:\temp\easy_install-naj8bw\ReportLab_2_3\src\rl_addons\rl_accel\_rl_accel.c(1279)
: warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible
loss of data
LINK : fatal error LNK1181: cannot open input file '_renderPM_libart.lib'
################################################
#Attempting install of _rl_accel, sgmlop & pyHnj
#extensions from
'c:\\temp\\easy_install-naj8bw\\ReportLab_2_3\\src\\rl_addons\\rl_accel'
################################################
################################################
#Attempting install of _renderPM
#extensions from
'c:\\temp\\easy_install-naj8bw\\ReportLab_2_3\\src\\rl_addons\\renderPM'
# installing with win32 freetype 'freetype214'
################################################
error: Setup script exited with error: command '"c:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\link.exe"' failed with
exit status 1181

--
/sorin
http://nusunt.eu

From IStevens at globeandmail.com  Thu Nov  5 13:40:19 2009
From: IStevens at globeandmail.com (Stevens, Ian)
Date: Thu, 5 Nov 2009 13:40:19 -0500
Subject: [reportlab-users] Intermittent failure to find font,
 followed by IOError
In-Reply-To: <4AF2AC1A.6010402@chamonix.reportlab.co.uk>
References: <DBA10110A4D98644A505089C2313187103DC63BC@GMTOMB01.globeandmail.net><956003ae0901191437pe94829ctd39af7b19a8bb50c@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6419@GMTOMB01.globeandmail.net>
	<956003ae0901200939g3d13a289ob80296b40e2923cc@mail.gmail.com><DBA10110A4D98644A505089C2313187103DC6426@GMTOMB01.globeandmail.net><4976168A.2050406@chamonix.reportlab.co.uk>
	<DBA10110A4D98644A505089C2313187103DC6435@GMTOMB01.globeandmail.net>
	<935E6400826049439C33D7BC3DC930360CEF7F30@GMEXMBS1.globeandmail.net>
	<4AE824C5.5070102@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF7F7D@GMEXMBS1.globeandmail.net>
	<4AE9A9FE.6040306@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80BA@GMEXMBS1.globeandmail.net>
	<4AF1593B.6030000@chamonix.reportlab.co.uk>
	<935E6400826049439C33D7BC3DC930360CEF80E4@GMEXMBS1.globeandmail.net>
	<935E6400826049439C33D7BC3DC930360CEF80F8@GMEXMBS1.globeandmail.net>
	<4AF2AC1A.6010402@chamonix.reportlab.co.uk>
Message-ID: <935E6400826049439C33D7BC3DC930360CEF8122@GMEXMBS1.globeandmail.net>

Yes, I'm fairly certain that's what's happening here. If we had a single domain name for our PDFs then this wouldn't be an issue. Come to think of it, I think the errors may have starting happening when we introduced a second domain. That new domain just happened to coincide with a new release, and new traffic, so we investigated from that end.

Our operations team has applied the PythonInterpreter change to production. We'll be monitoring it. 

Thanks for your help,
Ian.

> -----Original Message-----
> From: reportlab-users-bounces at lists2.reportlab.com 
> [mailto:reportlab-users-bounces at lists2.reportlab.com] On 
> Behalf Of Robin Becker
> Sent: November 5, 2009 5:43 AM
> To: For users of Reportlab open source software
> Subject: Re: [reportlab-users] Intermittent failure to find 
> font, followed by IOError
> 
> Stevens, Ian wrote:
> ......
> 
> Python guru Martin v. Loewis says this
> 
> > Restricted mode is still available, and activated whenever 
> a frame's 
> > builtins directory is different from the interpreter's; see 
> > PyFrame_IsRestricted.
> 
> so if your requests are somehow being passed around to 
> different interpreters that would cause this.
> --
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
> 

From paul.barrass at safeonlinebilling.com  Thu Nov  5 14:58:49 2009
From: paul.barrass at safeonlinebilling.com (Paul Barrass)
Date: Thu, 05 Nov 2009 19:58:49 +0000
Subject: [reportlab-users] reportlab fail installing on Windows 7 x64
 with Python 2.6 x64 (easy_install)
In-Reply-To: <d77cce480911050908j6711cbe3qaa598b46b4ff790@mail.gmail.com>
References: <d77cce480911050908j6711cbe3qaa598b46b4ff790@mail.gmail.com>
Message-ID: <4AF32E79.4050106@safeonlinebilling.com>

Sorin Sbarnea wrote:
> I remarked that easy_install reportlab fails with below errror on
> Windows 7 x64 with Python 2.6 x64:
>   
It's an FAQ that easy_install of Reportlab isn't supported/recommended - 
I think the latest official thread on this is:

http://two.pairlist.net/pipermail/reportlab-users/2009-May/008253.html


Paul Barrass.

From meitham at reportlab.com  Fri Nov  6 05:16:08 2009
From: meitham at reportlab.com (meitham)
Date: Fri, 06 Nov 2009 10:16:08 +0000
Subject: [reportlab-users] Five issues with AreaLinePlot
In-Reply-To: <3C08C2A9-5968-408D-A27D-0D894604855C@darwin.in-berlin.de>
References: <3C08C2A9-5968-408D-A27D-0D894604855C@darwin.in-berlin.de>
Message-ID: <4AF3F768.50604@reportlab.com>

> I've identified five issues with LineAreaPlots and attach sample
> code and output illustrating these. Here's a list from the code:
> 
>     # issue 1: gridline appears on top border, but not on bottom
>     # border: (ideally, it should not appear on any borders)
> 
The grid lines are actually appearing on both top and bottom border,
however the bottom grid line is overwritten with the x axis since you
set chart.gridFirst=True. If you set set the
chart.xValueAxis.visible=False you will be able to see the gridLine on
the bottom. This is not a bug.

>     # issue 2: right borderline (red) is overpainted by chart areas:
> 
chart.stroke was never intended to be used as a chart border. The
property is there as a consequence of architectural inheritance.
Hopefully this property will disappear in reportlab 3.0 with the use of
meta classes.

If you want to draw a border around your chart you can draw a rectangle.
from reportlab.graphics.shapes import Rect
drawing.background = Rect(chart.x,chart.y, chart.width,
chart.height,strokeColor=red,fillColor=None)

>     # issue 3: True/False has no effect (grid is always on top):
> 
The effect of chart.gridFirst is whether the the grid should be drawn
before the axis or after, not before the chart (area chart in your
example). There are two similar properties to achieve that on the axises
chart.xValueAxis.drawGridLast and chart.yValueAxis.drawGridLast. The
only way to solve this is by adding a Z axis (depth) where chart
components can have different values on that axis which controls the
order of drawing.


>     # issue 4: True/False has no effect (labels are always shown,
>     # if lineLabelFormat != None):
> 
This bug has been fixed.

>     # issue 5: label format cannot be a callable:
>     # chart.lineLabelFormat = lambda val:"%s" % ("i" * val)
> 
This bug has been fixed.

Best regards
Meitham

From meitham at reportlab.com  Fri Nov  6 05:59:35 2009
From: meitham at reportlab.com (meitham)
Date: Fri, 06 Nov 2009 10:59:35 +0000
Subject: [reportlab-users] Further AreaLinePlot bugs
In-Reply-To: <35A568D0-607A-4F3D-AF32-F7D003B2D426@darwin.in-berlin.de>
References: <3C1C3EB6-EB68-46A8-BD13-18131225DC1E@darwin.in-berlin.de>	<AFA9F6F9-377F-4026-B553-2D41A7201530@darwin.in-berlin.de>	<4A7C4ACB.2090409@chamonix.reportlab.co.uk>	<956003ae0908090405q24519d2aja521c5a31352b1c1@mail.gmail.com>
	<35A568D0-607A-4F3D-AF32-F7D003B2D426@darwin.in-berlin.de>
Message-ID: <4AF40197.2020808@reportlab.com>

> It should be easy to make
> this an option in the ValueAxis, named "onlyDataPointTicks" or
> something like that.
You could use a NormalDateXValueAxis() as your category axis. If you
browse into its properties you can see some fine controls like
maximumTicks, MinimumTickSpacing (in points), forceDatesEachYear which
if you supply with list of dates it will override the automatic ticking
algorithm.

Meitham

From sorin.sbarnea at gmail.com  Fri Nov  6 11:42:12 2009
From: sorin.sbarnea at gmail.com (Sorin Sbarnea)
Date: Fri, 6 Nov 2009 18:42:12 +0200
Subject: [reportlab-users] reportlab fail installing on Windows 7 x64
	with Python 2.6 x64 (easy_install)
In-Reply-To: <4AF32E79.4050106@safeonlinebilling.com>
References: <d77cce480911050908j6711cbe3qaa598b46b4ff790@mail.gmail.com> 
	<4AF32E79.4050106@safeonlinebilling.com>
Message-ID: <d77cce480911060842u7331af75s82992a1a862073f0@mail.gmail.com>

Thanks Paul,

This is really sad because easy_install is very good to install python stuff.

I tried the manual approach, installed pil without problems.

Now regarding freetype, I installed latest binary distribution from
http://sourceforge.net/projects/gnuwin32/files/freetype/
freetype-2.3.5-1-setup.exe

This installed under C:\Program Files (x86)\GnuWin32

I had to make a symlink from "C:\Program Files
(x86)\GnuWin32\include\freetype2\freetype" to "C:\Program Files
(x86)\GnuWin32\include\freetype" because the ft2build.h containts:
#include <freetype/config/ftheader.h>

Now I modified the setup.cfg file and added:
lib=C:\Program Files (x86)\GnuWin32\lib\freetype.lib
incdir=C:\Program Files (x86)\GnuWin32\include

Now it does compile but not linking (see below). Also in order to make
my life "easier" I use Python x64 and I'm pretty sure that freetype is
not compiled for x64 but this is not the reason why I get these
errors.

################################################
#Attempting install of _rl_accel, sgmlop & pyHnj
#extensions from 'C:\\dev\\pj\\kit\\py\\ReportLab_2_3\\src\\rl_addons\\rl_accel'
################################################
################################################
#Attempting install of _renderPM
#extensions from 'C:\\dev\\pj\\kit\\py\\ReportLab_2_3\\src\\rl_addons\\renderPM'
# installing with win32 freetype 'freetype'
################################################
running build
running build_py
copying src\reportlab\lib\hyphen.mashed -> build\lib.win-amd64-2.6\reportlab\lib
running build_clib
building '_renderPM_libart' library
building '_renderPM_gt1' library
running build_ext
building '_renderPM' extension
c:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\BIN\amd64\link.exe /DLL /nologo /INCREMENTAL:NO
"/LIBPATH:C:\Program Files (x86)\GnuWin32\lib"
/LIBPATH:C:\Python26\libs /LIBPATH:C:\Python26\PCbuild\amd64
/LIBPATH:build\temp.win-amd64-2.6 freetype.lib _renderPM_libart.lib
_renderPM_gt1.lib /EXPORT:init_renderPM
build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.obj
/OUT:build\lib.win-amd64-2.6\_renderPM.pyd
/IMPLIB:build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.lib
/MANIFESTFILE:build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.pyd.manifest
   Creating library
build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.lib
and object build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.exp
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_New_Memory_Face referenced in function _get_ft_face
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Init_FreeType referenced in function _get_ft_face
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Done_Face referenced in function py_FT_font_dealloc
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Outline_Decompose referenced in function
_ft_get_glyph_outline
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Load_Glyph referenced in function _ft_get_glyph_outline
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Get_Char_Index referenced in function _ft_get_glyph_outline
build\lib.win-amd64-2.6\_renderPM.pyd : fatal error LNK1120: 6
unresolved externals
error: command '"c:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\BIN\amd64\link.exe"' failed with exit status 1120

I just hope we'll solve this and be able to improve the install
*experience* for Windows.

Thanks,
--
/sorin
http://nusunt.eu

On Thu, Nov 5, 2009 at 21:58, Paul Barrass
<paul.barrass at safeonlinebilling.com> wrote:
> Sorin Sbarnea wrote:
>>
>> I remarked that easy_install reportlab fails with below errror on
>> Windows 7 x64 with Python 2.6 x64:
>>
>
> It's an FAQ that easy_install of Reportlab isn't supported/recommended - I
> think the latest official thread on this is:
>
> http://two.pairlist.net/pipermail/reportlab-users/2009-May/008253.html
>
>
> Paul Barrass.
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>

From andy at reportlab.com  Fri Nov  6 12:56:16 2009
From: andy at reportlab.com (Andy Robinson)
Date: Fri, 6 Nov 2009 17:56:16 +0000
Subject: [reportlab-users] reportlab fail installing on Windows 7 x64
	with Python 2.6 x64 (easy_install)
In-Reply-To: <d77cce480911060842u7331af75s82992a1a862073f0@mail.gmail.com>
References: <d77cce480911050908j6711cbe3qaa598b46b4ff790@mail.gmail.com>
	<4AF32E79.4050106@safeonlinebilling.com>
	<d77cce480911060842u7331af75s82992a1a862073f0@mail.gmail.com>
Message-ID: <956003ae0911060956v20e22ed5ldb436beb993dad13@mail.gmail.com>

2009/11/6 Sorin Sbarnea <sorin.sbarnea at gmail.com>:
> Thanks Paul,
> This is really sad because easy_install is very good to install python stuff.

For our next release we'll put some effort into supporting it.   I'm
hoping this will be December/January.

On our last release we found at the last minute that easy_install
conflicts with some long-term deployment arrangements of our own
customers' installations, and just didn't have time for another code
rearrangement.  I can't remember what the actual problem was.

We do NOT plan to adopt setuptools, but we hope to make it so you can
'easy_install reportlab'.

- Andy

From sorin.sbarnea at gmail.com  Fri Nov  6 13:56:56 2009
From: sorin.sbarnea at gmail.com (Sorin Sbarnea)
Date: Fri, 6 Nov 2009 20:56:56 +0200
Subject: [reportlab-users] reportlab fail installing on Windows 7 x64
	with Python 2.6 x64 (easy_install)
In-Reply-To: <956003ae0911060956v20e22ed5ldb436beb993dad13@mail.gmail.com>
References: <d77cce480911050908j6711cbe3qaa598b46b4ff790@mail.gmail.com> 
	<4AF32E79.4050106@safeonlinebilling.com>
	<d77cce480911060842u7331af75s82992a1a862073f0@mail.gmail.com> 
	<956003ae0911060956v20e22ed5ldb436beb993dad13@mail.gmail.com>
Message-ID: <d77cce480911061056v4ac5069cne31cc37a8678883f@mail.gmail.com>

> We do NOT plan to adopt setuptools, but we hope to make it so you can
> 'easy_install reportlab'.
Thanks for clarifying this - not lets go back to the build issues of
reportlab because I think anyone would benefit from a reportlab that
is easy to build.

Latest release of code does give this errors when you try setup.py
build (and you have right settings in setup.cfg):
C:\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.c(1885)
: warning C4244: '=' : conversion from '__int64' to 'long', possible
loss of data
c:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\BIN\amd64\link.exe /DLL /nologo /INCREMENTAL:NO
"/LIBPATH:C:\Program Files (x86)\GnuWin32\lib"
/LIBPATH:C:\Python26\libs /LIBPATH:C:\Python26\PCbuild\amd64
/LIBPATH:build\temp.win-amd64-2.6 freetype.lib _renderPM_libart.lib
_renderPM_gt1.lib /EXPORT:init_renderPM
build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.obj
/OUT:build\lib.win-amd64-2.6\_renderPM.pyd
/IMPLIB:build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.lib
/MANIFESTFILE:build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.pyd.manifest
   Creating library
build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.lib
and object build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.exp
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_New_Memory_Face referenced in function _get_ft_face
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Init_FreeType referenced in function _get_ft_face
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Done_Face referenced in function py_FT_font_dealloc
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Outline_Decompose referenced in function
_ft_get_glyph_outline
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Load_Glyph referenced in function _ft_get_glyph_outline
_renderPM.obj : error LNK2019: unresolved external symbol
__imp_FT_Get_Char_Index referenced in function _ft_get_glyph_outline
build\lib.win-amd64-2.6\_renderPM.pyd : fatal error LNK1120: 6
unresolved externals
error: command '"c:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\BIN\amd64\link.exe"' failed with exit status 1120

I checked and the symbols are inside the lib and I found an
wordaround: you go to .\src\rl_addons\renderPM\ where you run
"setup.py build" => in this case it does not complain at all.

Now you copy the library _renderPM.pyd from
.\src\rl_addons\renderPM\build\lib.win-amd64-2.6 to
.\build\lib.win-amd64-2.6 and you can run the "setup.py build" again
and "setup.py install".

After this reportlab is installed and running very well (at least the tests).

Now my question would be: why does this happen and how can we repair
this build issue?

--
/sorin

From mtromp.docbook at gmail.com  Sat Nov  7 22:57:05 2009
From: mtromp.docbook at gmail.com (Marcel Tromp)
Date: Sat, 7 Nov 2009 19:57:05 -0800
Subject: [reportlab-users] Image.getBounds bug
Message-ID: <72ab9d6b0911071957g696b9e46g317d39b4f7eb4950@mail.gmail.com>

Image.getBounds has a bug:

Found in Release 2.1, but present in 2.3 as well.

    def getBounds(self):
        return (self.x, self.y, self.x + width, self.y + width)
Results in: NameError: global name 'width' is not defined

This is fixed by:
    def getBounds(self):
        return (self.x, self.y, self.x + self.width, self.y +
self.height)


Marcel
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091107/f92a64b7/attachment.html>

From mtromp.docbook at gmail.com  Sat Nov  7 23:15:18 2009
From: mtromp.docbook at gmail.com (Marcel Tromp)
Date: Sat, 7 Nov 2009 20:15:18 -0800
Subject: [reportlab-users] Loading transparent GIFs with shapes.Image
Message-ID: <72ab9d6b0911072015y5e06d37as27b408537c6e4a3f@mail.gmail.com>

I am generating a pdf that includes transparent GIFs. The Image object does
not seem to honor transparency (ie, the image is overwriting other part of
the drawing where it should not.

Is there a way to use the GIF transparency?

MT
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091107/34d051df/attachment.html>

From robin at reportlab.com  Mon Nov  9 05:23:09 2009
From: robin at reportlab.com (Robin Becker)
Date: Mon, 09 Nov 2009 10:23:09 +0000
Subject: [reportlab-users] reportlab fail installing on Windows 7 x64
 with Python 2.6 x64 (easy_install)
In-Reply-To: <d77cce480911061056v4ac5069cne31cc37a8678883f@mail.gmail.com>
References: <d77cce480911050908j6711cbe3qaa598b46b4ff790@mail.gmail.com>
	<4AF32E79.4050106@safeonlinebilling.com>	<d77cce480911060842u7331af75s82992a1a862073f0@mail.gmail.com>
	<956003ae0911060956v20e22ed5ldb436beb993dad13@mail.gmail.com>
	<d77cce480911061056v4ac5069cne31cc37a8678883f@mail.gmail.com>
Message-ID: <4AF7ED8D.7070406@chamonix.reportlab.co.uk>

Sorin Sbarnea wrote:
>> We do NOT plan to adopt setuptools, but we hope to make it so you can
>> 'easy_install reportlab'.
> Thanks for clarifying this - not lets go back to the build issues of
> reportlab because I think anyone would benefit from a reportlab that
> is easy to build.
> 
> Latest release of code does give this errors when you try setup.py
> build (and you have right settings in setup.cfg):
> C:\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.c(1885)
> : warning C4244: '=' : conversion from '__int64' to 'long', possible
> loss of data
> c:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\BIN\amd64\link.exe /DLL /nologo /INCREMENTAL:NO
> "/LIBPATH:C:\Program Files (x86)\GnuWin32\lib"
> /LIBPATH:C:\Python26\libs /LIBPATH:C:\Python26\PCbuild\amd64
> /LIBPATH:build\temp.win-amd64-2.6 freetype.lib _renderPM_libart.lib
> _renderPM_gt1.lib /EXPORT:init_renderPM
> build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.obj
> /OUT:build\lib.win-amd64-2.6\_renderPM.pyd
> /IMPLIB:build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.lib
> /MANIFESTFILE:build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.pyd.manifest
>    Creating library
> build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.lib
> and object build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.exp
> _renderPM.obj : error LNK2019: unresolved external symbol
> __imp_FT_New_Memory_Face referenced in function _get_ft_face
> _renderPM.obj : error LNK2019: unresolved external symbol
> __imp_FT_Init_FreeType referenced in function _get_ft_face
> _renderPM.obj : error LNK2019: unresolved external symbol
> __imp_FT_Done_Face referenced in function py_FT_font_dealloc
> _renderPM.obj : error LNK2019: unresolved external symbol
> __imp_FT_Outline_Decompose referenced in function
> _ft_get_glyph_outline
> _renderPM.obj : error LNK2019: unresolved external symbol
> __imp_FT_Load_Glyph referenced in function _ft_get_glyph_outline
> _renderPM.obj : error LNK2019: unresolved external symbol
> __imp_FT_Get_Char_Index referenced in function _ft_get_glyph_outline
> build\lib.win-amd64-2.6\_renderPM.pyd : fatal error LNK1120: 6
> unresolved externals
> error: command '"c:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\BIN\amd64\link.exe"' failed with exit status 1120

this error just looks as though the build is attempting to include freetype 
support, but the load is failing to see the libraries.

> 
> I checked and the symbols are inside the lib and I found an
> wordaround: you go to .\src\rl_addons\renderPM\ where you run
> "setup.py build" => in this case it does not complain at all.
> 

the setup.py in the renderPM folder is the original (prior to the attempted 
merge of the builds). It may do slightly different things to locate things like 
FT lib etc etc; in particular  don't think it looks at all at cfg files (of 
course distutils may do that anyhow).

I have never built a 64bit version of anything under win32 so won't know 
anything about how that should be done; also I don't think I've yet had to use 
VS 9, which python are you building for?


> Now you copy the library _renderPM.pyd from
> .\src\rl_addons\renderPM\build\lib.win-amd64-2.6 to
> .\build\lib.win-amd64-2.6 and you can run the "setup.py build" again
> and "setup.py install".
> 
> After this reportlab is installed and running very well (at least the tests).
> 
> Now my question would be: why does this happen and how can we repair
> this build issue?
> 
> --
> /sorin
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
> 


-- 
Robin Becker

From sorin.sbarnea at gmail.com  Mon Nov  9 05:35:17 2009
From: sorin.sbarnea at gmail.com (=?utf-8?Q?Sorin_Sb=C3=A2rnea?=)
Date: Mon, 9 Nov 2009 12:35:17 +0200
Subject: [reportlab-users] reportlab fail installing on Windows 7 x64
	with Python 2.6 x64 (easy_install)
In-Reply-To: <4AF7ED8D.7070406@chamonix.reportlab.co.uk>
References: <d77cce480911050908j6711cbe3qaa598b46b4ff790@mail.gmail.com>
	<4AF32E79.4050106@safeonlinebilling.com>
	<d77cce480911060842u7331af75s82992a1a862073f0@mail.gmail.com>
	<956003ae0911060956v20e22ed5ldb436beb993dad13@mail.gmail.com>
	<d77cce480911061056v4ac5069cne31cc37a8678883f@mail.gmail.com>
	<4AF7ED8D.7070406@chamonix.reportlab.co.uk>
Message-ID: <A9DF3AC6-AE0B-4930-81EC-1BCE48EF8D3D@gmail.com>

  I am building for Python 2.6. I am using Python x64 build. As you  
can see there are lots of warnings but if you want  I could try to  
solve or hide them.

Doesn't make sense to call the origial setup.py for renderpm? at least  
this one works.
/sorin

Pe 09.11.2009, la 12:23, Robin Becker <robin at reportlab.com> a scris:

> Sorin Sbarnea wrote:
>>> We do NOT plan to adopt setuptools, but we hope to make it so you  
>>> can
>>> 'easy_install reportlab'.
>> Thanks for clarifying this - not lets go back to the build issues of
>> reportlab because I think anyone would benefit from a reportlab that
>> is easy to build.
>> Latest release of code does give this errors when you try setup.py
>> build (and you have right settings in setup.cfg):
>> C:\dev\pj\kit\py\ReportLab_2_3\src\rl_addons\renderPM\_renderPM.c 
>> (1885)
>> : warning C4244: '=' : conversion from '__int64' to 'long', possible
>> loss of data
>> c:\Program Files (x86)\Microsoft Visual Studio
>> 9.0\VC\BIN\amd64\link.exe /DLL /nologo /INCREMENTAL:NO
>> "/LIBPATH:C:\Program Files (x86)\GnuWin32\lib"
>> /LIBPATH:C:\Python26\libs /LIBPATH:C:\Python26\PCbuild\amd64
>> /LIBPATH:build\temp.win-amd64-2.6 freetype.lib _renderPM_libart.lib
>> _renderPM_gt1.lib /EXPORT:init_renderPM
>> build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src 
>> \rl_addons\renderPM\_renderPM.obj
>> /OUT:build\lib.win-amd64-2.6\_renderPM.pyd
>> /IMPLIB:build\temp.win-amd64-2.6\Release\dev\pj\kit\py 
>> \ReportLab_2_3\src\rl_addons\renderPM\_renderPM.lib
>> /MANIFESTFILE:build\temp.win-amd64-2.6\Release\dev\pj\kit\py 
>> \ReportLab_2_3\src\rl_addons\renderPM\_renderPM.pyd.manifest
>>   Creating library
>> build\temp.win-amd64-2.6\Release\dev\pj\kit\py\ReportLab_2_3\src 
>> \rl_addons\renderPM\_renderPM.lib
>> and object build\temp.win-amd64-2.6\Release\dev\pj\kit\py 
>> \ReportLab_2_3\src\rl_addons\renderPM\_renderPM.exp
>> _renderPM.obj : error LNK2019: unresolved external symbol
>> __imp_FT_New_Memory_Face referenced in function _get_ft_face
>> _renderPM.obj : error LNK2019: unresolved external symbol
>> __imp_FT_Init_FreeType referenced in function _get_ft_face
>> _renderPM.obj : error LNK2019: unresolved external symbol
>> __imp_FT_Done_Face referenced in function py_FT_font_dealloc
>> _renderPM.obj : error LNK2019: unresolved external symbol
>> __imp_FT_Outline_Decompose referenced in function
>> _ft_get_glyph_outline
>> _renderPM.obj : error LNK2019: unresolved external symbol
>> __imp_FT_Load_Glyph referenced in function _ft_get_glyph_outline
>> _renderPM.obj : error LNK2019: unresolved external symbol
>> __imp_FT_Get_Char_Index referenced in function _ft_get_glyph_outline
>> build\lib.win-amd64-2.6\_renderPM.pyd : fatal error LNK1120: 6
>> unresolved externals
>> error: command '"c:\Program Files (x86)\Microsoft Visual Studio
>> 9.0\VC\BIN\amd64\link.exe"' failed with exit status 1120
>
> this error just looks as though the build is attempting to include  
> freetype support, but the load is failing to see the libraries.
>
>> I checked and the symbols are inside the lib and I found an
>> wordaround: you go to .\src\rl_addons\renderPM\ where you run
>> "setup.py build" => in this case it does not complain at all.
>
> the setup.py in the renderPM folder is the original (prior to the  
> attempted merge of the builds). It may do slightly different things  
> to locate things like FT lib etc etc; in particular  don't think it  
> looks at all at cfg files (of course distutils may do that anyhow).
>
> I have never built a 64bit version of anything under win32 so won't  
> know anything about how that should be done; also I don't think I've  
> yet had to use VS 9, which python are you building for?
>
>
>> Now you copy the library _renderPM.pyd from
>> .\src\rl_addons\renderPM\build\lib.win-amd64-2.6 to
>> .\build\lib.win-amd64-2.6 and you can run the "setup.py build" again
>> and "setup.py install".
>> After this reportlab is installed and running very well (at least  
>> the tests).
>> Now my question would be: why does this happen and how can we repair
>> this build issue?
>> --
>> /sorin
>> _______________________________________________
>> reportlab-users mailing list
>> reportlab-users at lists2.reportlab.com
>> http://two.pairlist.net/mailman/listinfo/reportlab-users
>
>
> -- 
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users

From reportlab at benjamin-dumke.de  Mon Nov  9 06:32:59 2009
From: reportlab at benjamin-dumke.de (Benjamin Dumke)
Date: Mon, 9 Nov 2009 12:32:59 +0100 (MET)
Subject: [reportlab-users] Bug: String exception raised in pdfdoc.py
Message-ID: <200911091132.nA9BWxee005830@post.webmailer.de>

Hi,

line 1416 in pdfbase/pdfdoc.py (reportlab 2.3) reads

        raise "in outline, destination name must be string: got a %s" % Ot

Since string exceptions are illegal since Python 2.6, this raises a type error. Proposed fix:

        raise Exception("in outline, destination name must be string: got a %s" % Ot)

Greets

Ben

From meitham at reportlab.com  Mon Nov  9 06:48:45 2009
From: meitham at reportlab.com (Meitham Jamaa)
Date: Mon, 9 Nov 2009 11:48:45 +0000
Subject: [reportlab-users] Bug: String exception raised in pdfdoc.py
In-Reply-To: <200911091132.nA9BWxee005830@post.webmailer.de>
References: <200911091132.nA9BWxee005830@post.webmailer.de>
Message-ID: <881636dd0911090348xc71b29bmfcedfa228c5fed08@mail.gmail.com>

> Since string exceptions are illegal since Python 2.6, this raises a type error. Proposed fix:
>
> ? ? ? ?raise Exception("in outline, destination name must be string: got a %s" % Ot)

Thank you for reporting this issue.
This will now raise a TypeError.

Cheers
Meitham

From meitham at reportlab.com  Mon Nov  9 06:51:39 2009
From: meitham at reportlab.com (Meitham Jamaa)
Date: Mon, 9 Nov 2009 11:51:39 +0000
Subject: [reportlab-users] Image.getBounds bug
In-Reply-To: <72ab9d6b0911071957g696b9e46g317d39b4f7eb4950@mail.gmail.com>
References: <72ab9d6b0911071957g696b9e46g317d39b4f7eb4950@mail.gmail.com>
Message-ID: <881636dd0911090351u1b46a81ag58bd1ff8888eb26@mail.gmail.com>

> This is fixed by:
> ??? def getBounds(self):
> ??????? return (self.x, self.y, self.x + self.width, self.y +
> self.height)
>
> Marcel

Thank you for reporting the issue, your patch has been incorporated.

Cheers
Meitham

From mtromp.docbook at gmail.com  Wed Nov 11 16:21:06 2009
From: mtromp.docbook at gmail.com (Marcel Tromp)
Date: Wed, 11 Nov 2009 13:21:06 -0800
Subject: [reportlab-users] Loading transparent GIFs with shapes.Image
In-Reply-To: <72ab9d6b0911072015y5e06d37as27b408537c6e4a3f@mail.gmail.com>
References: <72ab9d6b0911072015y5e06d37as27b408537c6e4a3f@mail.gmail.com>
Message-ID: <72ab9d6b0911111321h61ac30e7ncf54af7ad485ad47@mail.gmail.com>

Anyone? Is there anyway to have overlapping bitmap images that use
transparency to show the lower/earlier image?

MT
--

On Sat, Nov 7, 2009 at 8:15 PM, Marcel Tromp <mtromp.docbook at gmail.com>wrote:

> I am generating a pdf that includes transparent GIFs. The Image object does
> not seem to honor transparency (ie, the image is overwriting other part of
> the drawing where it should not.
>
> Is there a way to use the GIF transparency?
>
> MT
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091111/5d5ed5d4/attachment.html>

From ulf.renman at favoptic.com  Thu Nov 12 04:19:29 2009
From: ulf.renman at favoptic.com (Ulf Renman)
Date: Thu, 12 Nov 2009 10:19:29 +0100
Subject: [reportlab-users] How can I stripe the grid
Message-ID: <4AFBD321.1050407@favoptic.com>

Hi

I use a LinePlot with dates on the x-axis. How can I make the grid so 
that the columns for Saturday and Sunday be highligted?

/Ulf

From robin at reportlab.com  Thu Nov 12 07:58:18 2009
From: robin at reportlab.com (Robin Becker)
Date: Thu, 12 Nov 2009 12:58:18 +0000
Subject: [reportlab-users] Loading transparent GIFs with shapes.Image
In-Reply-To: <72ab9d6b0911111321h61ac30e7ncf54af7ad485ad47@mail.gmail.com>
References: <72ab9d6b0911072015y5e06d37as27b408537c6e4a3f@mail.gmail.com>
	<72ab9d6b0911111321h61ac30e7ncf54af7ad485ad47@mail.gmail.com>
Message-ID: <4AFC066A.20705@chamonix.reportlab.co.uk>

Marcel Tromp wrote:
> Anyone? Is there anyway to have overlapping bitmap images that use
> transparency to show the lower/earlier image?
> 
I don't believe that shapes.Image supports any notion of transparency. Al of the 
reportlab graphs renderers depend explicitly on properties of the different back 
ends so it's fairly hard to support some of the more advanced concepts like 
overPrint and transparency.

You don't say which back end is being used. If you want to put images onto a PDF 
document then the pdfgen canvas already supports bitmaps with RGBA and a 
transparent colour.

If you're talking about the PM renderer then that's not done. The code is in 
renderPM.py
> 	def drawImage(self, image):
> 		if image.path and os.path.exists(image.path):
> 			if type(image.path) is type(''):
> 				im = _getImage().open(image.path).convert('RGB')
> 			else:
> 				im = image.path.convert('RGB')
> 			srcW, srcH = im.size
> 			dstW, dstH = image.width, image.height
> 			if dstW is None: dstW = srcW
> 			if dstH is None: dstH = srcH
> 			self._canvas._aapixbuf(
> 					image.x, image.y, dstW, dstH,
> 					im.tostring(), srcW, srcH, 3,
> 					)


so we would need to modify this.

Effectively im is a PIL image and we mash it directly onto our internal RGB 
buffer using libart's function art_rgb_pixbuf_affine.

Libart does have a function art_rgb_rgba_affine which could be used to mash an 
RGBA style image onto the RGB canvas. That would allow RGB + transparent colour 
or RGBA style sources to be used for the incoming image. Of course then we'd 
need to start looking at the Image processing for the other graphics renderers.
-- 
Robin Becker

From ulf.renman at favoptic.com  Thu Nov 12 08:39:27 2009
From: ulf.renman at favoptic.com (Ulf Renman)
Date: Thu, 12 Nov 2009 14:39:27 +0100
Subject: [reportlab-users] How can I stripe the grid
In-Reply-To: <4AFBD321.1050407@favoptic.com>
References: <4AFBD321.1050407@favoptic.com>
Message-ID: <4AFC100F.9060309@favoptic.com>

I solved this myself with the code below. Any comments on that?

weekColors = [
    colors.white,
    colors.white,
    colors.white,
    colors.white,
    colors.white,
    colors.Color(0.7,0.7,0.7),
    colors.Color(0.9,0.7,0.7),
    ]
def fun(data):
    drawing = Drawing(w,h)
    lp = LinePlot()

    <snip>

    # Create the grid.
    #   Use the same size and position as the LinePlot
    #   Calculate the gridstep by checking the actual data
    #   Offset it by half a step to make the grid better aligned with 
the data
    #   Calculate the order of the striping by getting the weekday of 
the first
    #     data point.
    grid = Grid()
    grid.x = lp.x
    grid.y = lp.y
    grid.width = lp.width
    grid.height = lp.height
    grid.delta = 20
    mi = data[0]['date'].toordinal()
    ma = data[-1]['date'].toordinal()
    grid.delta = float(grid.width)/(ma-mi)
    grid.delta0 = grid.delta/2
    wd = int(date.fromordinal(mi).strftime('%u'))-1
    grid.stripeColors = (weekColors+weekColors)[wd:wd+len(weekColors)]
    grid.useLines = 1
    grid.useRects = 1
    grid.strokeWidth = 0.3
    drawing.add(grid)

    # Add the LinePlot after the grid since we want it to be painted on top
    # of the grid.
    drawing.add(lp)


Ulf Renman wrote:
> Hi
>
> I use a LinePlot with dates on the x-axis. How can I make the grid so 
> that the columns for Saturday and Sunday be highligted?
>
> /Ulf
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users


From kevin.smith at sixquickrun.com  Fri Nov 13 12:13:05 2009
From: kevin.smith at sixquickrun.com (Kevin D Smith)
Date: Fri, 13 Nov 2009 11:13:05 -0600
Subject: [reportlab-users] RGBA support for colors?
Message-ID: <4E689CA1-A39B-4EFD-B6F6-F5B6850DC575@sixquickrun.com>

Is there any way to specify an alpha value for colors in ReportLAB  
(like in CSS3)?  I don't see anything in the documentation, but I'm  
hoping that I just missed it.

Kevin D Smith
Kevin.Smith at sixquickrun.com




From robin at reportlab.com  Fri Nov 13 12:31:07 2009
From: robin at reportlab.com (Robin Becker)
Date: Fri, 13 Nov 2009 17:31:07 +0000
Subject: [reportlab-users] RGBA support for colors?
In-Reply-To: <4E689CA1-A39B-4EFD-B6F6-F5B6850DC575@sixquickrun.com>
References: <4E689CA1-A39B-4EFD-B6F6-F5B6850DC575@sixquickrun.com>
Message-ID: <4AFD97DB.5030902@chamonix.reportlab.co.uk>

Kevin D Smith wrote:
> Is there any way to specify an alpha value for colors in ReportLAB (like 
> in CSS3)?  I don't see anything in the documentation, but I'm hoping 
> that I just missed it.
.......
something was added recently related to transparency after a user contribution. 
I'm almost sure it only affects PDF.
-- 
Robin Becker

From robin at reportlab.com  Fri Nov 13 12:31:07 2009
From: robin at reportlab.com (Robin Becker)
Date: Fri, 13 Nov 2009 17:31:07 +0000
Subject: [reportlab-users] RGBA support for colors?
In-Reply-To: <4E689CA1-A39B-4EFD-B6F6-F5B6850DC575@sixquickrun.com>
References: <4E689CA1-A39B-4EFD-B6F6-F5B6850DC575@sixquickrun.com>
Message-ID: <4AFD97DB.5030902@chamonix.reportlab.co.uk>

Kevin D Smith wrote:
> Is there any way to specify an alpha value for colors in ReportLAB (like 
> in CSS3)?  I don't see anything in the documentation, but I'm hoping 
> that I just missed it.
.......
something was added recently related to transparency after a user contribution. 
I'm almost sure it only affects PDF.
-- 
Robin Becker

From Kevin.Smith at sixquickrun.com  Fri Nov 13 14:44:21 2009
From: Kevin.Smith at sixquickrun.com (Kevin D Smith)
Date: Fri, 13 Nov 2009 13:44:21 -0600
Subject: [reportlab-users] RGBA support for colors?
In-Reply-To: <4AFD97DB.5030902@chamonix.reportlab.co.uk>
References: <4E689CA1-A39B-4EFD-B6F6-F5B6850DC575@sixquickrun.com>
	<4AFD97DB.5030902@chamonix.reportlab.co.uk>
Message-ID: <B92917BD-1054-4A56-9E0D-0E069C809476@sixquickrun.com>

I did notice that, but I think that only applied to images.  I was  
looking for opacity values for colors.

On Nov 13, 2009, at 11:31 AM, Robin Becker wrote:

> Kevin D Smith wrote:
>> Is there any way to specify an alpha value for colors in ReportLAB  
>> (like in CSS3)?  I don't see anything in the documentation, but I'm  
>> hoping that I just missed it.
> .......
> something was added recently related to transparency after a user  
> contribution. I'm almost sure it only affects PDF.
> -- 
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users

Kevin D Smith
Kevin.Smith at sixquickrun.com




From Kevin.Smith at sixquickrun.com  Fri Nov 13 14:44:21 2009
From: Kevin.Smith at sixquickrun.com (Kevin D Smith)
Date: Fri, 13 Nov 2009 13:44:21 -0600
Subject: [reportlab-users] RGBA support for colors?
In-Reply-To: <4AFD97DB.5030902@chamonix.reportlab.co.uk>
References: <4E689CA1-A39B-4EFD-B6F6-F5B6850DC575@sixquickrun.com>
	<4AFD97DB.5030902@chamonix.reportlab.co.uk>
Message-ID: <B92917BD-1054-4A56-9E0D-0E069C809476@sixquickrun.com>

I did notice that, but I think that only applied to images.  I was  
looking for opacity values for colors.

On Nov 13, 2009, at 11:31 AM, Robin Becker wrote:

> Kevin D Smith wrote:
>> Is there any way to specify an alpha value for colors in ReportLAB  
>> (like in CSS3)?  I don't see anything in the documentation, but I'm  
>> hoping that I just missed it.
> .......
> something was added recently related to transparency after a user  
> contribution. I'm almost sure it only affects PDF.
> -- 
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users

Kevin D Smith
Kevin.Smith at sixquickrun.com




From jeff.oneill at openstv.org  Sat Nov 14 11:51:08 2009
From: jeff.oneill at openstv.org (Jeffrey O'Neill)
Date: Sat, 14 Nov 2009 11:51:08 -0500
Subject: [reportlab-users] getting PDF page labels
Message-ID: <c361da770911140851t2a332e57sf1ee35dd3a0fa84c@mail.gmail.com>

A couple of weeks ago, Christian Jacobsen posted a great example of
how to set the page labels so that a document could have pages, e.g.,
i, ii, ... vi, 1, 2, ..., 100.  I'm pasting that example below for
reference.

Is there a way to access the pdf page labels so that I can use them in
drawing the page numbers on the page and including them in a table of
contents?

Jeff


-------------8<-------------------8<-------------------8<------------------
from reportlab.pdfgen import canvas
from reportlab.lib.units import cm
c = canvas.Canvas("page_numbering.pdf")
c.addPageLabel(c.getPageNumber()-1, 'ROMAN_LOWER')
for num in ['i', 'ii', 'iii', 'iv', 'v']:
    c.drawString(3*cm, 3*cm, num)
    c.showPage()
c.addPageLabel(c.getPageNumber()-1, 'ARABIC')
for num in range(1,5):
    c.drawString(3*cm, 3*cm, str(num))
    c.showPage()
c.addPageLabel(c.getPageNumber()-1, 'ARABIC', 10)
for num in range(10,15):
    c.drawString(3*cm, 3*cm, str(num))
    c.showPage()
c.addPageLabel(c.getPageNumber()-1, 'ARABIC', prefix='A.')
for num in range(1,5):
    c.drawString(3*cm, 3*cm, 'A.' + str(num))
    c.showPage()
c.save()

From cljacobsen at gmail.com  Sat Nov 14 12:27:19 2009
From: cljacobsen at gmail.com (Christian Jacobsen)
Date: Sat, 14 Nov 2009 18:27:19 +0100
Subject: [reportlab-users] getting PDF page labels
In-Reply-To: <c361da770911140851t2a332e57sf1ee35dd3a0fa84c@mail.gmail.com>
References: <c361da770911140851t2a332e57sf1ee35dd3a0fa84c@mail.gmail.com>
Message-ID: <d61c98f70911140927l27a50648l2d981881e7be518d@mail.gmail.com>

I don't think you are going to find anything useful that you can
access to draw the page numbers. You will probably have to just keep
track of the numbering in your program and generate both PageLabels
and actual printed page numbers from your own page numbering data.

What is actually stored in the PDF is just a reference for each time
the page numbering changes. Each page does not store its page number
and numbering system, this is calculated by the PDF reader when the
page is displayed. Thus there is nothing which will let you query the
logical page number (PageLabel) of a particular page directly from the
PDF.

  Christian

2009/11/14 Jeffrey O'Neill <jeff.oneill at openstv.org>:
> A couple of weeks ago, Christian Jacobsen posted a great example of
> how to set the page labels so that a document could have pages, e.g.,
> i, ii, ... vi, 1, 2, ..., 100. ?I'm pasting that example below for
> reference.
>
> Is there a way to access the pdf page labels so that I can use them in
> drawing the page numbers on the page and including them in a table of
> contents?
>
> Jeff
>
>
> -------------8<-------------------8<-------------------8<------------------
> from reportlab.pdfgen import canvas
> from reportlab.lib.units import cm
> c = canvas.Canvas("page_numbering.pdf")
> c.addPageLabel(c.getPageNumber()-1, 'ROMAN_LOWER')
> for num in ['i', 'ii', 'iii', 'iv', 'v']:
> ? ?c.drawString(3*cm, 3*cm, num)
> ? ?c.showPage()
> c.addPageLabel(c.getPageNumber()-1, 'ARABIC')
> for num in range(1,5):
> ? ?c.drawString(3*cm, 3*cm, str(num))
> ? ?c.showPage()
> c.addPageLabel(c.getPageNumber()-1, 'ARABIC', 10)
> for num in range(10,15):
> ? ?c.drawString(3*cm, 3*cm, str(num))
> ? ?c.showPage()
> c.addPageLabel(c.getPageNumber()-1, 'ARABIC', prefix='A.')
> for num in range(1,5):
> ? ?c.drawString(3*cm, 3*cm, 'A.' + str(num))
> ? ?c.showPage()
> c.save()
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>

From jtk at yahoo.com  Mon Nov 16 11:00:19 2009
From: jtk at yahoo.com (Jeff Kowalczyk)
Date: Mon, 16 Nov 2009 16:00:19 +0000 (UTC)
Subject: [reportlab-users]
	=?utf-8?q?Reportlab_SVN_repository_inaccessible?=
	=?utf-8?q?_via_https=09with_recent_svn/neon_versions?=
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
Message-ID: <loom.20091116T165652-894@post.gmane.org>

Jeff Kowalczyk <jtk <at> yahoo.com> writes:
> The reportlab SVN repository is inaccessible via https for users
> with recent versions of neon, a dependency of subversion.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548773
> Debian Bug report logs - #548773
> [libneon27-gnutls] authentication to subversion via https fails 
> with "Insecure Algorithm" error

Could someone at RL take a look at this?

Thanks,
Jeff


From robin at reportlab.com  Mon Nov 16 11:21:23 2009
From: robin at reportlab.com (Robin Becker)
Date: Mon, 16 Nov 2009 16:21:23 +0000
Subject: [reportlab-users] Reportlab SVN repository inaccessible via
 https with recent svn/neon versions
In-Reply-To: <loom.20091116T165652-894@post.gmane.org>
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
	<loom.20091116T165652-894@post.gmane.org>
Message-ID: <4B017C03.2030301@chamonix.reportlab.co.uk>

Jeff Kowalczyk wrote:
> Jeff Kowalczyk <jtk <at> yahoo.com> writes:
>> The reportlab SVN repository is inaccessible via https for users
>> with recent versions of neon, a dependency of subversion.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548773
>> Debian Bug report logs - #548773
>> [libneon27-gnutls] authentication to subversion via https fails 
>> with "Insecure Algorithm" error
> 
> Could someone at RL take a look at this?
> 
> Thanks,
> Jeff
........
I guess this means a problem with recent ssl fixes. I guess we'll have to take 
that machine down and rebuild it from the ground up. It's running quite an old 
base system, but it sits near me so I can actually do that without too much terror.

I think Andy has planned me some time for that around Christmas. Can you say 
what the details of your subversion are? My colleagues are running karmic with 
1.6.5 and are not seeing that problem.
-- 
Robin Becker

From robin at reportlab.com  Mon Nov 16 11:21:23 2009
From: robin at reportlab.com (Robin Becker)
Date: Mon, 16 Nov 2009 16:21:23 +0000
Subject: [reportlab-users] Reportlab SVN repository inaccessible via
 https with recent svn/neon versions
In-Reply-To: <loom.20091116T165652-894@post.gmane.org>
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
	<loom.20091116T165652-894@post.gmane.org>
Message-ID: <4B017C03.2030301@chamonix.reportlab.co.uk>

Jeff Kowalczyk wrote:
> Jeff Kowalczyk <jtk <at> yahoo.com> writes:
>> The reportlab SVN repository is inaccessible via https for users
>> with recent versions of neon, a dependency of subversion.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548773
>> Debian Bug report logs - #548773
>> [libneon27-gnutls] authentication to subversion via https fails 
>> with "Insecure Algorithm" error
> 
> Could someone at RL take a look at this?
> 
> Thanks,
> Jeff
........
I guess this means a problem with recent ssl fixes. I guess we'll have to take 
that machine down and rebuild it from the ground up. It's running quite an old 
base system, but it sits near me so I can actually do that without too much terror.

I think Andy has planned me some time for that around Christmas. Can you say 
what the details of your subversion are? My colleagues are running karmic with 
1.6.5 and are not seeing that problem.
-- 
Robin Becker

From johnkeyes at gmail.com  Mon Nov 16 13:14:55 2009
From: johnkeyes at gmail.com (John Keyes)
Date: Mon, 16 Nov 2009 18:14:55 +0000
Subject: [reportlab-users] Reportlab SVN repository inaccessible via
	https with recent svn/neon versions
In-Reply-To: <4B017C03.2030301@chamonix.reportlab.co.uk>
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
	<loom.20091116T165652-894@post.gmane.org>
	<4B017C03.2030301@chamonix.reportlab.co.uk>
Message-ID: <21aa4c930911161014t4f079c0ap7ac4942641e1b383@mail.gmail.com>

FYI Beanstalk ran into this issue recently. See:

http://help.beanstalkapp.com/discussions/problems/435-ssl-connection-to-svn-failing-after-migration

-John K



On Mon, Nov 16, 2009 at 4:21 PM, Robin Becker <robin at reportlab.com> wrote:
> Jeff Kowalczyk wrote:
>>
>> Jeff Kowalczyk <jtk <at> yahoo.com> writes:
>>>
>>> The reportlab SVN repository is inaccessible via https for users
>>> with recent versions of neon, a dependency of subversion.
>>>
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548773
>>> Debian Bug report logs - #548773
>>> [libneon27-gnutls] authentication to subversion via https fails with
>>> "Insecure Algorithm" error
>>
>> Could someone at RL take a look at this?
>>
>> Thanks,
>> Jeff
>
> ........
> I guess this means a problem with recent ssl fixes. I guess we'll have to
> take that machine down and rebuild it from the ground up. It's running quite
> an old base system, but it sits near me so I can actually do that without
> too much terror.
>
> I think Andy has planned me some time for that around Christmas. Can you say
> what the details of your subversion are? My colleagues are running karmic
> with 1.6.5 and are not seeing that problem.
> --
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>



-- 
me: http://www.keyes.ie/

charities: http://www.oxfam.ie | http://www.bothar.org | http://www.ipcc.ie

From haly at centrivision.com  Tue Nov 17 09:30:54 2009
From: haly at centrivision.com (Hosam Aly)
Date: Tue, 17 Nov 2009 16:30:54 +0200
Subject: [reportlab-users] RTL Support
In-Reply-To: <956003ae0909290331gf05c0a2ha32c57b7dd0d01d7@mail.gmail.com>
References: <956003ae0909290331gf05c0a2ha32c57b7dd0d01d7@mail.gmail.com>
Message-ID: <4B02B39E.2080805@centrivision.com>

An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091117/4de29f50/attachment.htm>

From haly at centrivision.com  Tue Nov 17 09:42:40 2009
From: haly at centrivision.com (Hosam Aly)
Date: Tue, 17 Nov 2009 16:42:40 +0200
Subject: [reportlab-users] RTL Support
In-Reply-To: <4B02B39E.2080805@centrivision.com>
References: <4B02B39E.2080805@centrivision.com>
Message-ID: <4B02B660.3060609@centrivision.com>

Hello,


I would like to contribute to supporting RTL texts within ReportLab. I 
have seen some previous work by Moshe Wagner, and I would like to help too.

I just hope to have some help or guidance from you, as I am relatively 
new to ReportLab. Meanwhile, I will start by trying Moshe's patch.


Regards,

Hosam Aly
Software Engineer
http://www.linkedin.com/in/hosamaly


From robin at reportlab.com  Tue Nov 17 10:05:31 2009
From: robin at reportlab.com (Robin Becker)
Date: Tue, 17 Nov 2009 15:05:31 +0000
Subject: [reportlab-users] Reportlab SVN repository inaccessible via
 https with recent svn/neon versions
In-Reply-To: <loom.20091116T165652-894@post.gmane.org>
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
	<loom.20091116T165652-894@post.gmane.org>
Message-ID: <4B02BBBB.8050406@chamonix.reportlab.co.uk>

Jeff Kowalczyk wrote:
> Jeff Kowalczyk <jtk <at> yahoo.com> writes:
>> The reportlab SVN repository is inaccessible via https for users
>> with recent versions of neon, a dependency of subversion.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548773
>> Debian Bug report logs - #548773
>> [libneon27-gnutls] authentication to subversion via https fails 
>> with "Insecure Algorithm" error
> 
> Could someone at RL take a look at this?
...
anyone more knowledagable about what the real problem is here? I see some 
references to MD5 signing not being considered good enough etc etc, but that 
presumably means we have to get the crt remade. Is that what's required?
-- 
Robin Becker

From robin at reportlab.com  Tue Nov 17 12:45:56 2009
From: robin at reportlab.com (Robin Becker)
Date: Tue, 17 Nov 2009 17:45:56 +0000
Subject: [reportlab-users] Reportlab SVN repository inaccessible via
 https with recent svn/neon versions
In-Reply-To: <loom.20091116T165652-894@post.gmane.org>
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
	<loom.20091116T165652-894@post.gmane.org>
Message-ID: <4B02E154.4030908@chamonix.reportlab.co.uk>

Jeff Kowalczyk wrote:
> Jeff Kowalczyk <jtk <at> yahoo.com> writes:
>> The reportlab SVN repository is inaccessible via https for users
>> with recent versions of neon, a dependency of subversion.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548773
>> Debian Bug report logs - #548773
>> [libneon27-gnutls] authentication to subversion via https fails 
>> with "Insecure Algorithm" error
> 
> Could someone at RL take a look at this?
> 
> Thanks,
> Jeff
........

Our server also works in http: so that should fix your problems wrt md5/trust 
etc etc. Not sure exactly why we advertise everything in https, we use https for 
checking in though. Up to now https hasn't been a problem.
-- 
Robin Becker

From haly at centrivision.com  Tue Nov 17 13:19:59 2009
From: haly at centrivision.com (Hosam Aly)
Date: Tue, 17 Nov 2009 20:19:59 +0200
Subject: [reportlab-users] Hebrew Support Patch
In-Reply-To: <b7e0dc2f0906080142p7a7ee08cm7c3136d40274f06b@mail.gmail.com>
References: <b7e0dc2f0906080142p7a7ee08cm7c3136d40274f06b@mail.gmail.com>
Message-ID: <4B02E94F.1090105@centrivision.com>

Hello,


I have been reading through Moshe's patch, and I noticed a few things.


First, the code that Moshe suggested for `Canvas.drawString` should 
actually be placed at the very beginning of `PDFTextObject._formatText`, 
because that's where all string writing methods eventually go (as far as 
I understand).


Second, paragraph direction should not be associated with paragraph 
alignment. Any paragraph can be aligned left or right, and that does not 
change its direction, being LTR or RTL. So we need to have a flag that 
tells the paragraph direction, and this flag should be set by the 
caller. This is the same as what is done in HTML: you can specify 
`dir="RTL"` as an attribute on most tags, and it does not affect text 
alignment. So I suggest adding a "direction" property to 
`platypus.paragraph`, whose value by default is LTR.


Moreover, there is no need for the code in `platypus.paragraph`. It is 
sufficient to use `pyfribidi.log2vis` in `PDFTextObject._formatText` 
with automatic detection for most cases, but we should pass the 
paragraph direction to the pyfribidi function so as to get correct 
output for some corner cases (e.g. when symbols come at the end of the 
line).

I am working on supporting RTL functionality right now, and I will 
follow up with a patch very soon.


Best regards,

Hosam Aly
Software Engineer
Centrivision (http://www.centrivision.com/)
http://www.linkedin.com/in/hosamaly


From haly at centrivision.com  Tue Nov 17 13:23:24 2009
From: haly at centrivision.com (Hosam Aly)
Date: Tue, 17 Nov 2009 20:23:24 +0200
Subject: [reportlab-users] RTL Support
Message-ID: <4B02EA1C.5010401@centrivision.com>

Hello,


I have been working on supporting RTL functionality (as I described in 
my previous message), and I was able to get much of this working by 
adding just 1 line of code to the `PDFTextObject._formatText` function 
(not counting some imports). I have also created a test case in 
`test_paragraphs.py`, and it is working relatively fine. There are still 
some corner cases to be addressed (as mentioned above), but they are 
relatively rare. More work still needs to be done to support paragraph 
direction and different character shapes (according to whether the 
character appears at the beginning, the middle or the end of the word).

Please find attached a patch file for the latest revision on the public 
Subversion repository as of the time of writing this message (revision 
3585, 2009-11-17 4:42 PM). I am also writing it down below for the archive.



Best regards,


Hosam Aly

Software Engineer

Centrivision (http://www.centrivision.com/)

http://www.linkedin.com/in/hosamaly




--- BEGIN PATCH ---

Index: src/reportlab/pdfgen/textobject.py
===================================================================
--- src/reportlab/pdfgen/textobject.py    (revision 3585)
+++ src/reportlab/pdfgen/textobject.py    (working copy)
@@ -15,6 +15,17 @@
 from reportlab.lib.utils import fp_str
 from reportlab.pdfbase import pdfmetrics
 
+# try to import pyfribidi
+try:
+    import pyfribidi
+    log2vis = pyfribidi.log2vis
+    DIR_ON = pyfribidi.ON
+except:
+    import warnings
+    warnings.warn('pyfribidi is not installed - RTL not supported')
+    log2vis = None
+    DIR_ON = None
+
 class _PDFColorSetter:
     '''Abstracts the color setting operations; used in Canvas and 
Textobject
     asseumes we have a _code object'''
@@ -329,6 +340,15 @@
 
     def _formatText(self, text):
         "Generates PDF text output operator(s)"
+        ###################################################
+        # RTL text patch, Hosam Aly, November 2009
+        # <haly at centrivision.com>
+        # Based on the patch by Moshe Wagner, June 2009
+        # <moshe.wagner at gmail.com>
+        # Use pyfribidi to write the text in the correct visual order.
+        text = log2vis(text, base_direction = DIR_ON)
+        ###################################################
+
         canv = self._canvas
         font = pdfmetrics.getFont(self._fontname)
         R = []
Index: tests/test_paragraphs.py
===================================================================
--- tests/test_paragraphs.py    (revision 3583)
+++ tests/test_paragraphs.py    (working copy)
@@ -160,6 +160,55 @@
                                      showBoundary=1)
         template.build(story,
             onFirstPage=myFirstPage, onLaterPages=myLaterPages)
+   
+    def test1(self):
+        def registerFont(filename):
+            from reportlab.pdfbase import pdfmetrics
+            from reportlab.pdfbase import ttfonts
+            from reportlab.lib.fonts import addMapping
+       
+            face = ttfonts.TTFontFace(filename)
+            pdfmetrics.registerFont(ttfonts.TTFont(face.name, filename, 
asciiReadable=0))
+            addMapping(face.familyName, face.bold, face.italic, face.name)
+
+        import os
+        fontDir = 'ttf-dejavu'
+        fontName = 'DejaVuSans'
+        registerFont(os.path.join('/usr/share/fonts/truetype/', 
fontDir, fontName + '.ttf'))
+
+
+        story = []
+
+        #need a style
+        from reportlab.lib.enums import TA_RIGHT
+        styNormal = ParagraphStyle('normal', fontName = fontName, 
alignment = TA_RIGHT)
+        styGreen = ParagraphStyle('green',parent=styNormal,textColor=green)
+
+        # some to test
+        stySpaced = ParagraphStyle('spaced',
+                                   parent=styNormal,
+                                   spaceBefore=12,
+                                   spaceAfter=12)
+
+
+        story.append(
+            Paragraph('\xd9\x87\xd8\xb0\xd9\x87 
\xd9\x81\xd9\x82\xd8\xb1\xd8\xa9 
\xd8\xb9\xd8\xa7\xd8\xaf\xd9\x8a\xd8\xa9. ', styNormal))
+        story.append(
+            Paragraph('\xd9\x87\xd8\xb0\xd9\x87 
\xd8\xa7\xd9\x84\xd9\x81\xd9\x82\xd8\xb1\xd8\xa9 
\xd9\x84\xd8\xaf\xd9\x8a\xd9\x87\xd8\xa7 12 
\xd9\x86\xd9\x82\xd8\xb7\xd8\xa9 
\xd9\x82\xd8\xa8\xd9\x84\xd9\x87\xd8\xa7 
\xd9\x88\xd8\xa8\xd8\xb9\xd8\xaf\xd9\x87\xd8\xa7. ', stySpaced))
+        story.append(
+            Paragraph('\xd9\x87\xd8\xb0\xd9\x87 
\xd8\xa7\xd9\x84\xd9\x81\xd9\x82\xd8\xb1\xd8\xa9 
\xd8\xb9\xd8\xa7\xd8\xaf\xd9\x8a\xd8\xa9. ' +
+                      randomText(), styNormal))
+
+        story.append(
+            Paragraph('<para spacebefore="12" spaceafter="12">' +
+                        '\xd9\x87\xd8\xb0\xd9\x87 
\xd8\xa7\xd9\x84\xd9\x81\xd9\x82\xd8\xb1\xd8\xa9 
\xd9\x84\xd8\xaf\xd9\x8a\xd9\x87\xd8\xa7 12 
\xd9\x86\xd9\x82\xd8\xb7\xd8\xa9 
\xd9\x82\xd8\xa8\xd9\x84\xd9\x87\xd8\xa7 
\xd9\x88\xd8\xa8\xd8\xb9\xd8\xaf\xd9\x87\xd8\xa7\xd8\x8c 
\xd9\x85\xd8\xad\xd8\xaf\xd8\xaf\xd8\xa9 \xd8\xa8\xd9\x80 XML. 
\xd8\xa5\xd9\x86\xd9\x87\xd8\xa7 \xd8\xaa\xd8\xb9\xd9\x85\xd9\x84 
\xd8\xa3\xd9\x8a\xd8\xb6\xd8\xa7! \xd9\x80.'*5
+                         +'</para',
+                      styNormal))
+
+        template = SimpleDocTemplate(outputfile('test_paragraphs_ar.pdf'),
+                                     showBoundary=1)
+        template.build(story,
+            onFirstPage=myFirstPage, onLaterPages=myLaterPages)
 
 
 def makeSuite():

--- END PATCH ---

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reportlab-rtl.patch
Type: text/x-patch
Size: 4389 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091117/ca5db102/attachment.bin>

From jtk at yahoo.com  Tue Nov 17 16:31:15 2009
From: jtk at yahoo.com (Jeff Kowalczyk)
Date: Tue, 17 Nov 2009 21:31:15 +0000 (UTC)
Subject: [reportlab-users] Reportlab SVN repository inaccessible via
	https with recent svn/neon versions
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
	<loom.20091116T165652-894@post.gmane.org>
	<4B02E154.4030908@chamonix.reportlab.co.uk>
Message-ID: <loom.20091117T222651-46@post.gmane.org>

Robin Becker <robin <at> reportlab.com> writes:

> 
> Jeff Kowalczyk wrote:
> > Jeff Kowalczyk <jtk <at> yahoo.com> writes:
> >> The reportlab SVN repository is inaccessible via https for users
> >> with recent versions of neon, a dependency of subversion.
> >>
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548773
> >> Debian Bug report logs - #548773
> >> [libneon27-gnutls] authentication to subversion via https fails 
> >> with "Insecure Algorithm" error
> > 
> > Could someone at RL take a look at this?
> > 
> > Thanks,
> > Jeff
> ........
> 
> Our server also works in http: so that should fix your problems wrt md5/trust 
> etc etc. Not sure exactly why we advertise everything in https, we use 
> https for checking in though. Up to now https hasn't been a problem.

So it does, thanks. I just confirmed that an http checkout works fine:

$ svn co http://svn.reportlab.com/svn/public/reportlab/trunk reportlab

Previous messages to this group indicated that RL's ISP was not forwarding port
80 to the server, and for that reason HTTPS checkouts were necessary for all (at
the time).

Regarding the underlying issue, it appears that the certificate will need to be
remade, that is all. The recent versions of libneon et. al. reject MD5 signed
certificates as a matter of policy. The bug above indicated that they weren't
inclined to provide an override for the user.

Thanks,
Jeff


From yroman-reportlab at altalang.com  Tue Nov 17 16:35:47 2009
From: yroman-reportlab at altalang.com (Yoann Roman)
Date: Tue, 17 Nov 2009 16:35:47 -0500
Subject: [reportlab-users] RTL Support
In-Reply-To: <4B02B660.3060609@centrivision.com>
References: <4B02B39E.2080805@centrivision.com>
	<4B02B660.3060609@centrivision.com>
Message-ID: <00ce01ca67cd$ecede250$0502000a@ad.altalang.com>

> I would like to contribute to supporting RTL texts within ReportLab. 
> I have seen some previous work by Moshe Wagner, and I would like to 
> help too.
> 
> I just hope to have some help or guidance from you, as I am relatively 
> new to ReportLab. Meanwhile, I will start by trying Moshe's patch.

We deal with a large number of languages on a daily basis, and RTL 
support has been a real issue for us. Moshe's patch uses Pyfribidi, 
which we've also used successfully to get basic RTL support going.

The main issue we still have is with Arabic scripts. While Pyfribidi 
will do some Arabic shaping, it's really doing Unicode substitutions 
with the Arabic Presentation Forms blocks. Problem is those blocks are 
meant for legacy use and don't cover all possible combinations. We've 
run into incorrect shaping with Pashto, Farsi, and Dari so far.

I've yet to find anything in Python that deals with this.

-- 
Yoann Roman


From haly at centrivision.com  Wed Nov 18 04:32:31 2009
From: haly at centrivision.com (Hosam Aly)
Date: Wed, 18 Nov 2009 11:32:31 +0200
Subject: [reportlab-users] RTL Support
In-Reply-To: <00ce01ca67cd$ecede250$0502000a@ad.altalang.com>
Message-ID: <1258536751.1796.3.camel@haly-desktop>

I believe I can help with character shaping. I have done it before on a
Arabic scripts only, but I think I could improve it to support the
Unicode standard.

I'll also look for means to port it to Python, or at least to link with
a C library. I shall try to work on it this week. I hope some people are
willing to help (or at least to review the outcome).


Best regards,

Hosam Aly
Software Developer
http://www.linkedin.com/in/hosamaly



From andy at reportlab.com  Wed Nov 18 04:56:52 2009
From: andy at reportlab.com (Andy Robinson)
Date: Wed, 18 Nov 2009 09:56:52 +0000
Subject: [reportlab-users] Hebrew Support Patch
In-Reply-To: <4B02E94F.1090105@centrivision.com>
References: <b7e0dc2f0906080142p7a7ee08cm7c3136d40274f06b@mail.gmail.com>
	<4B02E94F.1090105@centrivision.com>
Message-ID: <956003ae0911180156j7d4c71e1w5eb598caa863f8fe@mail.gmail.com>

2009/11/17 Hosam Aly <haly at centrivision.com>:
> Hello,
> So I suggest
> adding a "direction" property to `platypus.paragraph`, whose value by
> default is LTR.

This makes a lot of sense to me but I'd like to consider one change.

We introduced a 'wordwrap' property into Platypus and RML a few years
back for Asian text support.   Default value is None. but 'CJK' (for
Asian text) is allowed and selects a different word-wrapping
algorithm.  This is heavily used - we generate tend of thousands of
pages of Japanese per day.

Would it work if we extended this to have
  wordwrap = None | CJK | RTL

?

(There are probably a few other weird ones, but we have no short-term
plans to support Mayan writing in concentric circles etc...and in the
long run, ReportLab 3 should just look at the Unicode code points and
figure out that it's Arabic/Hebrew or CJKV)

Opinions welcome from anyone.


> I am working on supporting RTL functionality right now, and I will follow up
> with a patch very soon.

That's great news and we welcome your input, as well as Yoann's.
We're now hoping to do a release in Dec or early Jan (yes, I know it
keeps slipping, but you'll shortly see some of the things which pushed
it back) and it would be great to have some of this in.  We also now
have an Arabic-speaking employee which will help us a lot.

I tried to play with this a while ago but could not get fribidi and/or
pyfribidi to work due to confusions over versions. If anyone could
post some precise instructions on exactly what to install (e.g. Ubuntu
packages, or precise source) that would help us get into this.

Best Regards,

-- 
Andy Robinson
CEO/Chief Architect
ReportLab

From andy at reportlab.com  Wed Nov 18 04:56:52 2009
From: andy at reportlab.com (Andy Robinson)
Date: Wed, 18 Nov 2009 09:56:52 +0000
Subject: [reportlab-users] Hebrew Support Patch
In-Reply-To: <4B02E94F.1090105@centrivision.com>
References: <b7e0dc2f0906080142p7a7ee08cm7c3136d40274f06b@mail.gmail.com>
	<4B02E94F.1090105@centrivision.com>
Message-ID: <956003ae0911180156j7d4c71e1w5eb598caa863f8fe@mail.gmail.com>

2009/11/17 Hosam Aly <haly at centrivision.com>:
> Hello,
> So I suggest
> adding a "direction" property to `platypus.paragraph`, whose value by
> default is LTR.

This makes a lot of sense to me but I'd like to consider one change.

We introduced a 'wordwrap' property into Platypus and RML a few years
back for Asian text support.   Default value is None. but 'CJK' (for
Asian text) is allowed and selects a different word-wrapping
algorithm.  This is heavily used - we generate tend of thousands of
pages of Japanese per day.

Would it work if we extended this to have
  wordwrap = None | CJK | RTL

?

(There are probably a few other weird ones, but we have no short-term
plans to support Mayan writing in concentric circles etc...and in the
long run, ReportLab 3 should just look at the Unicode code points and
figure out that it's Arabic/Hebrew or CJKV)

Opinions welcome from anyone.


> I am working on supporting RTL functionality right now, and I will follow up
> with a patch very soon.

That's great news and we welcome your input, as well as Yoann's.
We're now hoping to do a release in Dec or early Jan (yes, I know it
keeps slipping, but you'll shortly see some of the things which pushed
it back) and it would be great to have some of this in.  We also now
have an Arabic-speaking employee which will help us a lot.

I tried to play with this a while ago but could not get fribidi and/or
pyfribidi to work due to confusions over versions. If anyone could
post some precise instructions on exactly what to install (e.g. Ubuntu
packages, or precise source) that would help us get into this.

Best Regards,

-- 
Andy Robinson
CEO/Chief Architect
ReportLab

From andy at reportlab.com  Wed Nov 18 05:21:38 2009
From: andy at reportlab.com (Andy Robinson)
Date: Wed, 18 Nov 2009 10:21:38 +0000
Subject: [reportlab-users] Reportlab SVN repository inaccessible via
	https with recent svn/neon versions
In-Reply-To: <loom.20091117T222651-46@post.gmane.org>
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
	<loom.20091116T165652-894@post.gmane.org>
	<4B02E154.4030908@chamonix.reportlab.co.uk>
	<loom.20091117T222651-46@post.gmane.org>
Message-ID: <956003ae0911180221w6b9cc1d3q99deb915ea5d23ea@mail.gmail.com>

2009/11/17 Jeff Kowalczyk <jtk at yahoo.com>:
> So it does, thanks. I just confirmed that an http checkout works fine:
>
> $ svn co http://svn.reportlab.com/svn/public/reportlab/trunk reportlab
>
> Previous messages to this group indicated that RL's ISP was not forwarding port
> 80 to the server, and for that reason HTTPS checkouts were necessary for all (at
> the time).

You're right there - we failed to re-inform the list once the problem
got better.

I have checked our web site which is telling people to use http://

> Regarding the underlying issue, it appears that the certificate will need to be
> remade, that is all. The recent versions of libneon et. al. reject MD5 signed
> certificates as a matter of policy. The bug above indicated that they weren't
> inclined to provide an override for the user.

OK, we'll try to fix this over Christmas and New Year when the
customers stop bugging us.   We followed step-by-step instructions on
our certificate vendor's web site with very little actual
understanding, so may need to get their input ;-(

- Andy

From andy at reportlab.com  Wed Nov 18 05:21:38 2009
From: andy at reportlab.com (Andy Robinson)
Date: Wed, 18 Nov 2009 10:21:38 +0000
Subject: [reportlab-users] Reportlab SVN repository inaccessible via
	https with recent svn/neon versions
In-Reply-To: <loom.20091117T222651-46@post.gmane.org>
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>
	<loom.20091116T165652-894@post.gmane.org>
	<4B02E154.4030908@chamonix.reportlab.co.uk>
	<loom.20091117T222651-46@post.gmane.org>
Message-ID: <956003ae0911180221w6b9cc1d3q99deb915ea5d23ea@mail.gmail.com>

2009/11/17 Jeff Kowalczyk <jtk at yahoo.com>:
> So it does, thanks. I just confirmed that an http checkout works fine:
>
> $ svn co http://svn.reportlab.com/svn/public/reportlab/trunk reportlab
>
> Previous messages to this group indicated that RL's ISP was not forwarding port
> 80 to the server, and for that reason HTTPS checkouts were necessary for all (at
> the time).

You're right there - we failed to re-inform the list once the problem
got better.

I have checked our web site which is telling people to use http://

> Regarding the underlying issue, it appears that the certificate will need to be
> remade, that is all. The recent versions of libneon et. al. reject MD5 signed
> certificates as a matter of policy. The bug above indicated that they weren't
> inclined to provide an override for the user.

OK, we'll try to fix this over Christmas and New Year when the
customers stop bugging us.   We followed step-by-step instructions on
our certificate vendor's web site with very little actual
understanding, so may need to get their input ;-(

- Andy

From haly at centrivision.com  Wed Nov 18 05:51:15 2009
From: haly at centrivision.com (Hosam Aly)
Date: Wed, 18 Nov 2009 12:51:15 +0200
Subject: [reportlab-users] Hebrew Support Patch
In-Reply-To: <956003ae0911180156j7d4c71e1w5eb598caa863f8fe@mail.gmail.com>
Message-ID: <1258541475.1796.26.camel@haly-desktop>

> Would it work if we extended this to have wordwrap = None | CJK | RTL?

I am not really aware about how this property is used. I'll have to
learn more about the code. It may be a good place, but I don't think the
there is need for a special word wrapping algorithm for Arabic. (I don't
know about other languages.)

> ... and in the long run, ReportLab 3 should just look at the Unicode
> code points and figure out that it's Arabic/Hebrew or CJKV)

I am not sure why ReportLab would need to do that. If you use the
fribidi library (or another similar library), the library itself should
be able to do that transparently.

> We're now hoping to do a release in Dec or early Jan, and it would
> be great to have some of this in.

That's great news. I hope we can get ReportLab to speak RTL languages
correctly in this release.

> If anyone could post some precise instructions on exactly what to
> install (e.g. Ubuntu packages, or precise source)

I have Ubuntu installed, and all I needed to do was:
apt-get install python-pyfribidi


As a side note, I'd prefer we continue the conversation on the RTL
thread, because the subject of this thread makes it harder for other
people to find it in search results (e.g. someone searching for
"reportlab farsi" or "reportlab arabic" in Google might find this thread
uninteresting, since it apparently talks about Hebrew only).


Best regards,

Hosam Aly
Software Engineer
http://www.linkedin.com/in/hosamaly


From robin at reportlab.com  Wed Nov 18 05:53:58 2009
From: robin at reportlab.com (Robin Becker)
Date: Wed, 18 Nov 2009 10:53:58 +0000
Subject: [reportlab-users] Reportlab SVN repository inaccessible
 via	https with recent svn/neon versions
In-Reply-To: <loom.20091117T222651-46@post.gmane.org>
References: <7128.32590.qm@web63408.mail.re1.yahoo.com>	<loom.20091116T165652-894@post.gmane.org>	<4B02E154.4030908@chamonix.reportlab.co.uk>
	<loom.20091117T222651-46@post.gmane.org>
Message-ID: <4B03D246.2010609@chamonix.reportlab.co.uk>

Jeff Kowalczyk wrote:
> Robin Becker <robin <at> reportlab.com> writes:
> 
>> Jeff Kowalczyk wrote:
>>> Jeff Kowalczyk <jtk <at> yahoo.com> writes:
>>>> The reportlab SVN repository is inaccessible via https for users
>>>> with recent versions of neon, a dependency of subversion.
>>>>
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548773
>>>> Debian Bug report logs - #548773
>>>> [libneon27-gnutls] authentication to subversion via https fails 
>>>> with "Insecure Algorithm" error
>>> Could someone at RL take a look at this?
>>>
>>> Thanks,
>>> Jeff
>> ........
>>
>> Our server also works in http: so that should fix your problems wrt md5/trust 
>> etc etc. Not sure exactly why we advertise everything in https, we use 
>> https for checking in though. Up to now https hasn't been a problem.
> 
> So it does, thanks. I just confirmed that an http checkout works fine:
> 
> $ svn co http://svn.reportlab.com/svn/public/reportlab/trunk reportlab
> 
> Previous messages to this group indicated that RL's ISP was not forwarding port
> 80 to the server, and for that reason HTTPS checkouts were necessary for all (at
> the time).
> 

I vaguely remember that issue was possibly related to moving into our new 
office, but cannot remember resolving it. It seems Jerome Alet had some issues 
Oct. 2008, but they appear to have been resolved then.


> Regarding the underlying issue, it appears that the certificate will need to be
> remade, that is all. The recent versions of libneon et. al. reject MD5 signed
> certificates as a matter of policy. The bug above indicated that they weren't
> inclined to provide an override for the user.
..........

I assume that's not something one is able to do without getting the CA to do it 
ie there's not some magic I can do with openssl software to convert my crt to a 
different signing algorithm.
-- 
Robin Becker

From andy at reportlab.com  Wed Nov 18 05:56:28 2009
From: andy at reportlab.com (Andy Robinson)
Date: Wed, 18 Nov 2009 10:56:28 +0000
Subject: [reportlab-users] Hebrew Support Patch
In-Reply-To: <1258541475.1796.26.camel@haly-desktop>
References: <956003ae0911180156j7d4c71e1w5eb598caa863f8fe@mail.gmail.com>
	<1258541475.1796.26.camel@haly-desktop>
Message-ID: <956003ae0911180256s146d5545v155f76f43df219ed@mail.gmail.com>

2009/11/18 Hosam Aly <haly at centrivision.com>:
> As a side note, I'd prefer we continue the conversation on the RTL
> thread, because the subject of this thread makes it harder for other
> people to find it in search results (e.g. someone searching for
> "reportlab farsi" or "reportlab arabic" in Google might find this thread
> uninteresting, since it apparently talks about Hebrew only).

Very good point.   I'll also add a page to our site about it to
summarise the status and tune in.

- Andy

From robin at reportlab.com  Wed Nov 18 06:41:02 2009
From: robin at reportlab.com (Robin Becker)
Date: Wed, 18 Nov 2009 11:41:02 +0000
Subject: [reportlab-users] RTL
In-Reply-To: <1258541475.1796.26.camel@haly-desktop>
References: <1258541475.1796.26.camel@haly-desktop>
Message-ID: <4B03DD4E.3000407@chamonix.reportlab.co.uk>

Andy says we should create an RTL branch and give you guys checkin rights etc etc.

I'm quite willing to do that, but should this be in


https://svn.reportlab.com/public/reportlab/community/branches

or

https://svn.reportlab.com/public/reportlab/branches

The community area hasn't received many (3) outside checkins.
-- 
Robin Becker

From yroman-reportlab at altalang.com  Wed Nov 18 08:19:12 2009
From: yroman-reportlab at altalang.com (Yoann Roman)
Date: Wed, 18 Nov 2009 08:19:12 -0500
Subject: [reportlab-users] RTL
In-Reply-To: <4B03DD4E.3000407@chamonix.reportlab.co.uk>
References: <1258541475.1796.26.camel@haly-desktop>
	<4B03DD4E.3000407@chamonix.reportlab.co.uk>
Message-ID: <003001ca6851$b7e8afc0$0502000a@ad.altalang.com>

> Andy says we should create an RTL branch and give you guys checkin 
> rights etc etc.
> 
> I'm quite willing to do that, but should this be in
> 
> https://svn.reportlab.com/public/reportlab/community/branches
> 
> or
> 
> https://svn.reportlab.com/public/reportlab/branches
> 
> The community area hasn't received many (3) outside checkins.

I missed the exchange that led to setting up a "community" repository, 
and Google is being uncooperative at helping me locate it. So what was 
the idea behind this? And how do changes in that repository get merged 
back into the main repository?

For the RTL support, it seems a branch under the main repository would 
make more sense since the changes should be minimal and getting them 
merged back into trunk as quickly as possible would benefit everyone 
needing this support. Then again, Hosam is much further along on this, 
so whatever works for him works for me.

-- 
Yoann Roman


From robin at reportlab.com  Wed Nov 18 08:31:16 2009
From: robin at reportlab.com (Robin Becker)
Date: Wed, 18 Nov 2009 13:31:16 +0000
Subject: [reportlab-users] RTL
In-Reply-To: <003001ca6851$b7e8afc0$0502000a@ad.altalang.com>
References: <1258541475.1796.26.camel@haly-desktop>	<4B03DD4E.3000407@chamonix.reportlab.co.uk>
	<003001ca6851$b7e8afc0$0502000a@ad.altalang.com>
Message-ID: <4B03F724.5000704@chamonix.reportlab.co.uk>

Yoann Roman wrote:
.........
> 
> I missed the exchange that led to setting up a "community" repository, 
> and Google is being uncooperative at helping me locate it. So what was 
> the idea behind this? And how do changes in that repository get merged 
> back into the main repository?
> 

I've just cross-merged them all. There wasn't a lot of pressure to do this anyhow.


> For the RTL support, it seems a branch under the main repository would 
> make more sense since the changes should be minimal and getting them 
> merged back into trunk as quickly as possible would benefit everyone 
> needing this support. Then again, Hosam is much further along on this, 
> so whatever works for him works for me.
> 

I think this is the best option. If you guys agree I will make a branch and then 
  make you both committers. We need a branch name and some user names.
-- 
Robin Becker

From yroman-reportlab at altalang.com  Wed Nov 18 08:52:05 2009
From: yroman-reportlab at altalang.com (Yoann Roman)
Date: Wed, 18 Nov 2009 08:52:05 -0500
Subject: [reportlab-users] RTL
In-Reply-To: <4B03F724.5000704@chamonix.reportlab.co.uk>
References: <1258541475.1796.26.camel@haly-desktop>	<4B03DD4E.3000407@chamonix.reportlab.co.uk><003001ca6851$b7e8afc0$0502000a@ad.altalang.com>
	<4B03F724.5000704@chamonix.reportlab.co.uk>
Message-ID: <003601ca6856$4ff394c0$0502000a@ad.altalang.com>

>> For the RTL support, it seems a branch under the main repository 
>> would make more sense since the changes should be minimal and getting 
>> them merged back into trunk as quickly as possible would benefit 
>> everyone needing this support. Then again, Hosam is much further 
>> along on this, so whatever works for him works for me.
> 
> I think this is the best option. If you guys agree I will make a 
> branch and then make you both committers. We need a branch name and 
> some user names.

"rtl-support"?

I don't have anything to commit at the moment. All of our RTL support 
was added outside of RL so we could keep using trunk without patching, 
and it's now fairly integrated into our other systems (e.g., we check 
available code points in a font after running Pyfribidi to determine the 
right one to use for each language). If you want to set this up now 
anyway, "yoann" is fine; I doubt you'll have 2 of those :-).

Thanks,

-- 
Yoann Roman


From haly at centrivision.com  Wed Nov 18 09:28:05 2009
From: haly at centrivision.com (Hosam Aly)
Date: Wed, 18 Nov 2009 16:28:05 +0200
Subject: [reportlab-users] RTL
In-Reply-To: <003601ca6856$4ff394c0$0502000a@ad.altalang.com>
References: <1258541475.1796.26.camel@haly-desktop>	<4B03DD4E.3000407@chamonix.reportlab.co.uk><003001ca6851$b7e8afc0$0502000a@ad.altalang.com>	<4B03F724.5000704@chamonix.reportlab.co.uk>
	<003601ca6856$4ff394c0$0502000a@ad.altalang.com>
Message-ID: <4B040475.2010603@centrivision.com>

Yoann Roman wrote:

>>> For the RTL support, it seems a branch under the main repository 
>>> would make more sense since the changes should be minimal and getting 
>>> them merged back into trunk as quickly as possible would benefit 
>>> everyone needing this support. Then again, Hosam is much further 
>>> along on this, so whatever works for him works for me.
>>>       
>> I think this is the best option. If you guys agree I will make a 
>> branch and then make you both committers. We need a branch name and 
>> some user names.
>>     
>
> "rtl-support"?
>
> I don't have anything to commit at the moment. All of our RTL support 
> was added outside of RL so we could keep using trunk without patching, 
> and it's now fairly integrated into our other systems (e.g., we check 
> available code points in a font after running Pyfribidi to determine the 
> right one to use for each language). If you want to set this up now 
> anyway, "yoann" is fine; I doubt you'll have 2 of those :-).
>
> Thanks,
>
>   
The branch name "rtl-support" seems fine to me. I prefer my username to 
be "hosamaly"


Thank you!

Hosam Aly
Software Engineer
http://www.linkedin.com/in/hosamaly


From timr at probo.com  Wed Nov 18 12:30:59 2009
From: timr at probo.com (Tim Roberts)
Date: Wed, 18 Nov 2009 09:30:59 -0800
Subject: [reportlab-users] Hebrew Support Patch
In-Reply-To: <956003ae0911180156j7d4c71e1w5eb598caa863f8fe@mail.gmail.com>
References: <b7e0dc2f0906080142p7a7ee08cm7c3136d40274f06b@mail.gmail.com>	<4B02E94F.1090105@centrivision.com>
	<956003ae0911180156j7d4c71e1w5eb598caa863f8fe@mail.gmail.com>
Message-ID: <4B042F53.6010904@probo.com>

Andy Robinson wrote:
> (There are probably a few other weird ones, but we have no short-term
> plans to support Mayan writing in concentric circles etc...

That's all right, I understand that worldwide support for Mayan writing
expires in 2012 anyway...

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.


From mtromp.docbook at gmail.com  Wed Nov 18 18:04:52 2009
From: mtromp.docbook at gmail.com (Marcel Tromp)
Date: Wed, 18 Nov 2009 15:04:52 -0800
Subject: [reportlab-users] Loading transparent GIFs with shapes.Image
In-Reply-To: <4AFC066A.20705@chamonix.reportlab.co.uk>
References: <72ab9d6b0911072015y5e06d37as27b408537c6e4a3f@mail.gmail.com>
	<72ab9d6b0911111321h61ac30e7ncf54af7ad485ad47@mail.gmail.com>
	<4AFC066A.20705@chamonix.reportlab.co.uk>
Message-ID: <72ab9d6b0911181504q123dcc35m12fe1e3383bf8a73@mail.gmail.com>

Target is pdf. However, I have not been using canvas in my scripts. So far I
have been grouping shapes (including images) in groups, which ultimately get
added to a Drawing, which get rendered to a pdf.

In this method, transparency does not work.

What is the benefit to use canvas instead beyond the image rendering?

MT
--



On Thu, Nov 12, 2009 at 4:58 AM, Robin Becker <robin at reportlab.com> wrote:

> Marcel Tromp wrote:
>
>> Anyone? Is there anyway to have overlapping bitmap images that use
>> transparency to show the lower/earlier image?
>>
>>  I don't believe that shapes.Image supports any notion of transparency. Al
> of the reportlab graphs renderers depend explicitly on properties of the
> different back ends so it's fairly hard to support some of the more advanced
> concepts like overPrint and transparency.
>
> You don't say which back end is being used. If you want to put images onto
> a PDF document then the pdfgen canvas already supports bitmaps with RGBA and
> a transparent colour.
>
> If you're talking about the PM renderer then that's not done. The code is
> in renderPM.py
>
>>        def drawImage(self, image):
>>                if image.path and os.path.exists(image.path):
>>                        if type(image.path) is type(''):
>>                                im =
>> _getImage().open(image.path).convert('RGB')
>>                        else:
>>                                im = image.path.convert('RGB')
>>                        srcW, srcH = im.size
>>                        dstW, dstH = image.width, image.height
>>                        if dstW is None: dstW = srcW
>>                        if dstH is None: dstH = srcH
>>                        self._canvas._aapixbuf(
>>                                        image.x, image.y, dstW, dstH,
>>                                        im.tostring(), srcW, srcH, 3,
>>                                        )
>>
>
>
> so we would need to modify this.
>
> Effectively im is a PIL image and we mash it directly onto our internal RGB
> buffer using libart's function art_rgb_pixbuf_affine.
>
> Libart does have a function art_rgb_rgba_affine which could be used to mash
> an RGBA style image onto the RGB canvas. That would allow RGB + transparent
> colour or RGBA style sources to be used for the incoming image. Of course
> then we'd need to start looking at the Image processing for the other
> graphics renderers.
> --
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091118/63c65df4/attachment.htm>

From haly at centrivision.com  Thu Nov 19 07:55:53 2009
From: haly at centrivision.com (Hosam Aly)
Date: Thu, 19 Nov 2009 14:55:53 +0200
Subject: [reportlab-users] RTL Patch Committed
Message-ID: <4B054059.1050208@centrivision.com>

Hello,


I have committed a patch to the "rtl-support" branch, adding partial RTL 
support in "src/reportlab/pdfgen/textobject.py" and 
"src/reportlab/platypus/paragraph", based on pyfribidi.


I have also created a set of test cases in "tests/test_paragraphs.py", 
in a method called testRTL.


I am attaching the results I got by running the test case, and the 
correct expected results, generated by OpenOffice.org's Writer.


Out of 15 test cases, 15 succeeded and 1 failed, which is the sixth one 
(line 6 in the generated PDF). The Arabic words should have appeared at 
the beginning of the line, but instead they appear at the end. This 
issue needs more investigation.


There is still the issue of connecting letters, but that's more related 
to Complex Text Layout (CTL) than it is to supporting BiDirectional 
rendering. I'll try to tackle that issue next. I am thinking of using 
PyICU instead of PyFriBiDi, but I still have to read more about it.


Meanwhile, I read in the PDF standard (version 1.7 from Adobe) that the 
PDF text object supports receiving UTF-16BE text, provided that it 
starts with the Unicode Byte Order Mark (BOM, U+FEFF). I wonder what 
would be the results if we wrote text in UTF-16 instead of writing the 
code points in the font? I didn't know how to test this, so I hope 
someone can help me.



Best regards,


Hosam Aly

Software Engineer

http://www.linkedin.com/in/hosamaly


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_paragraphs_ar.pdf
Type: application/pdf
Size: 21455 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091119/05fc6af8/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: correctResults.pdf
Type: application/pdf
Size: 22751 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091119/05fc6af8/attachment-0003.pdf>

From robin at reportlab.com  Thu Nov 19 08:46:30 2009
From: robin at reportlab.com (Robin Becker)
Date: Thu, 19 Nov 2009 13:46:30 +0000
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <4B054059.1050208@centrivision.com>
References: <4B054059.1050208@centrivision.com>
Message-ID: <4B054C36.10900@chamonix.reportlab.co.uk>

Hosam Aly wrote:
..........
> I have committed a patch to the "rtl-support" branch, adding partial RTL 
> support in "src/reportlab/pdfgen/textobject.py" and 
> "src/reportlab/platypus/paragraph", based on pyfribidi.
........

> 
> Out of 15 test cases, 15 succeeded and 1 failed, which is the sixth one 
> (line 6 in the generated PDF). The Arabic words should have appeared at 
> the beginning of the line, but instead they appear at the end. This 
> issue needs more investigation.
> 

thanks and great work.

> 
> There is still the issue of connecting letters, but that's more related 
> to Complex Text Layout (CTL) than it is to supporting BiDirectional 
> rendering. I'll try to tackle that issue next. I am thinking of using 
> PyICU instead of PyFriBiDi, but I still have to read more about it.
> 
> 
> Meanwhile, I read in the PDF standard (version 1.7 from Adobe) that the 
> PDF text object supports receiving UTF-16BE text, provided that it 
> starts with the Unicode Byte Order Mark (BOM, U+FEFF). I wonder what 
> would be the results if we wrote text in UTF-16 instead of writing the 
> code points in the font? I didn't know how to test this, so I hope 
> someone can help me.
..........
We have used UTF16 in some places in pdfdoc.py. I believe that was related to 
using CJK standard fonts in places where Acrobat Reader would normally use 
pdfdoc encoding ie various comments and document description sections.

In principle there's nothing that's better about using a 16bit unicode 
representation for text. I do see that for cmaps there are a lot of predefined 
mappings which correspond to various utf16 subsets.

When the font is a builtin font I can see that using a standard encoding makes 
sense. That is certainly the case for the standard AR cjk fonts where the fonts 
are large and don't have to be embedded. However, we are often making up subset 
fonts for embedding purposes and there I don't think it makes sense to use 16bit 
entries.
-- 
Robin Becker

From alsadi at gmail.com  Thu Nov 19 10:37:57 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 19 Nov 2009 17:37:57 +0200
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <4B054C36.10900@chamonix.reportlab.co.uk>
References: <4B054059.1050208@centrivision.com>
	<4B054C36.10900@chamonix.reportlab.co.uk>
Message-ID: <385866f0911190737j6603a3f9u2c3c6c2bedfcfc00@mail.gmail.com>

at last someone interested to help!

I'm very happy

> There is still the issue of connecting letters, but that's more related to Complex Text Layout (CTL)

I can make a transformation that takes a unicode object and shape it
to connect the letters if this is the

the algorithm is called mu [it can be called either before of after fribidi]

an old python implementation is attached

c implementation for wine
http://bugs.winehq.org/show_bug.cgi?id=7150

so would this solve some of the problems

and allow me to ask
when would be able to have full opentype support (as in harfbuzz)
instead of those hacks ?

http://www.freedesktop.org/wiki/Software/HarfBuzz

On Thu, Nov 19, 2009 at 3:46 PM, Robin Becker <robin at reportlab.com> wrote:
> Hosam Aly wrote:
> ..........
>>
>> I have committed a patch to the "rtl-support" branch, adding partial RTL
>> support in "src/reportlab/pdfgen/textobject.py" and
>> "src/reportlab/platypus/paragraph", based on pyfribidi.
>
> ........
>
>>
>> Out of 15 test cases, 15 succeeded and 1 failed, which is the sixth one
>> (line 6 in the generated PDF). The Arabic words should have appeared at the
>> beginning of the line, but instead they appear at the end. This issue needs
>> more investigation.
>>
>
> thanks and great work.
>
>>
>> There is still the issue of connecting letters, but that's more related to
>> Complex Text Layout (CTL) than it is to supporting BiDirectional rendering.
>> I'll try to tackle that issue next. I am thinking of using PyICU instead of
>> PyFriBiDi, but I still have to read more about it.
>>
>>
>> Meanwhile, I read in the PDF standard (version 1.7 from Adobe) that the
>> PDF text object supports receiving UTF-16BE text, provided that it starts
>> with the Unicode Byte Order Mark (BOM, U+FEFF). I wonder what would be the
>> results if we wrote text in UTF-16 instead of writing the code points in the
>> font? I didn't know how to test this, so I hope someone can help me.
>
> ..........
> We have used UTF16 in some places in pdfdoc.py. I believe that was related
> to using CJK standard fonts in places where Acrobat Reader would normally
> use pdfdoc encoding ie various comments and document description sections.
>
> In principle there's nothing that's better about using a 16bit unicode
> representation for text. I do see that for cmaps there are a lot of
> predefined mappings which correspond to various utf16 subsets.
>
> When the font is a builtin font I can see that using a standard encoding
> makes sense. That is certainly the case for the standard AR cjk fonts where
> the fonts are large and don't have to be embedded. However, we are often
> making up subset fonts for embedding purposes and there I don't think it
> makes sense to use 16bit entries.
> --
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mu.py
Type: application/octet-stream
Size: 10467 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091119/59a81a99/attachment.obj>

From yroman-reportlab at altalang.com  Thu Nov 19 10:56:21 2009
From: yroman-reportlab at altalang.com (Yoann Roman)
Date: Thu, 19 Nov 2009 10:56:21 -0500
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <4B054059.1050208@centrivision.com>
References: <4B054059.1050208@centrivision.com>
Message-ID: <008c01ca6930$d6e885f0$0502000a@ad.altalang.com>

Hosam Aly wrote...
> I have committed a patch to the "rtl-support" branch, adding partial 
> RTL support in "src/reportlab/pdfgen/textobject.py" and 
> "src/reportlab/platypus/paragraph", based on pyfribidi.

Thanks! I certainly appreciate the time you're putting into this, and 
I'm sure many others do as well.

> There is still the issue of connecting letters, but that's more 
> related to Complex Text Layout (CTL) than it is to supporting 
> BiDirectional rendering. I'll try to tackle that issue next. I am 
> thinking of using PyICU instead of PyFriBiDi, but I still have to read 
> more about it.

When I last looked into it, ICU did the same type of shaping as Fribidi; 
that is, it uses the legacy Arabic Presentation Forms blocks. These 
don't provide adequate coverage for Arabic script languages other than 
Arabic itself.

See:
http://icu-project.org/apiref/icu4c/ushape_8h.html#1f89291c5a24a50b8f6dcad5eb4
668f7

Modern Arabic shaping, as indicated in the above page, uses font glyph 
selection instead of replacing Unicode characters (which, among other 
things, affects text searches). In my research, the only library with 
Python bindings that *appears* to use this approach is Pango, but I 
haven't had time to test it out yet.

-- 
Yoann Roman


From andy at reportlab.com  Thu Nov 19 12:29:33 2009
From: andy at reportlab.com (Andy Robinson)
Date: Thu, 19 Nov 2009 17:29:33 +0000
Subject: [reportlab-users] Loading transparent GIFs with shapes.Image
In-Reply-To: <72ab9d6b0911181504q123dcc35m12fe1e3383bf8a73@mail.gmail.com>
References: <72ab9d6b0911072015y5e06d37as27b408537c6e4a3f@mail.gmail.com>
	<72ab9d6b0911111321h61ac30e7ncf54af7ad485ad47@mail.gmail.com>
	<4AFC066A.20705@chamonix.reportlab.co.uk>
	<72ab9d6b0911181504q123dcc35m12fe1e3383bf8a73@mail.gmail.com>
Message-ID: <956003ae0911190929l44e8483eu48a195a6e42c753a@mail.gmail.com>

2009/11/18 Marcel Tromp <mtromp.docbook at gmail.com>:
> What is the benefit to use canvas instead beyond the image rendering?

We wrote the canvas first, which aims to expose all the main PDF features.

A year or two later, our clients needed a charts library which could
output charts as bitmaps, PDF and Postscript.  reportlab/graphics can
take the Drawings and write them onto our Canvas, or similar renderers
for Postscript and bitmap formats.   Transparency only recently came
into the Canvas, but nobodyhas  needed or asked for it in the charts
library (and our customers really only use it for charts; nobody would
want a transparent axis or data line as far as I can see...)

There are probably many PDF features not implemented in
reportlab/graphics and logically we ought to add it when it works in
all backends, but we have not done so yet.

I hope this makes it clearer....

Best Regards,

-- 
Andy Robinson
CEO/Chief Architect
ReportLab Europe Ltd.
Media House, 3 Palmerston Road, Wimbledon, London SW19 1PG, UK
Tel +44-20-8545-1570

From alsadi at gmail.com  Thu Nov 19 13:37:39 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 19 Nov 2009 20:37:39 +0200
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
References: <4B054059.1050208@centrivision.com>
	<008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
Message-ID: <385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>

no need for icu, my mu.py works

I've add mu.py in reportlab/pdfgen/ and after importing pyfribidi I put
from mu import shape as muShape

then replaced
text = log2vis(text, directions.get(self.direction, DIR_ON))

with
text = log2vis(muShape(text), directions.get(self.direction, DIR_ON))


here is the result of
 import reportlab.rl_config
reportlab.rl_config.warnOnMissingFontGlyphs = 0
from reportlab.pdfbase import pdfmetrics
from reportlab.pdfbase.ttfonts import TTFont
pdfmetrics.registerFont(TTFont('Sans',
'/usr/share/fonts/dejavu/DejaVuSans.ttf'))
from reportlab.pdfgen import canvas
c = canvas.Canvas("hello.pdf")
c.setFont("Sans", 14)
c.drawString(100,100,"???? ????".decode('utf-8'))
c.showPage()
c.save()
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.pdf
Type: application/pdf
Size: 24444 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091119/5762cab1/attachment-0001.pdf>

From yroman-reportlab at altalang.com  Thu Nov 19 14:53:07 2009
From: yroman-reportlab at altalang.com (Yoann Roman)
Date: Thu, 19 Nov 2009 14:53:07 -0500
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>
References: <4B054059.1050208@centrivision.com><008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
	<385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>
Message-ID: <00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>

Muayyad AlSadi wrote...
> no need for icu, my mu.py works
> 
> I've add mu.py in reportlab/pdfgen/ and after importing pyfribidi I 
> put from mu import shape as muShape
> 
> then replaced
> text = log2vis(text, directions.get(self.direction, DIR_ON))
> 
> with
> text = log2vis(muShape(text), directions.get(self.direction, DIR_ON))

What does your mu.py do differently than Fribidi's Arabic shaping? It 
still seems to be font-independent, so I assume you're doing Unicode 
character substitution. If that's the case, since the RTL support 
requires Fribidi, why not use Fribidi's shaping as well?

-- 
Yoann Roman


From alsadi at gmail.com  Thu Nov 19 15:23:45 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 19 Nov 2009 22:23:45 +0200
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>
References: <4B054059.1050208@centrivision.com>
	<008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
	<385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>
	<00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>
Message-ID: <385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com>

> What does your mu.py do differently than Fribidi's Arabic shaping?
here is the problem,  python fribidi does not do shaping at all,
that's why we need to pass shaped text to fribidi's log2vis

fribidi do support shaping but its python binding does not offer that
see
http://pyfribidi.sourceforge.net/

I guess you talk about fribidi_shape
but pyfribidi only provide fribidi_shape


BTW:
while testing mu I noticed many places that depends on ascii strings
not unicode object for example I needed to edit
platypus/doctemplate.py
from
        if type(pt) is StringType:
to make it
        if  isinstance(pt,basestring):

and I noticed that there are several hard-coded front names in platypus
in several files, I suggest making them in one file that can be passed
as argument or derive a class based on it ..etc.

I modified my share in mu.py to be

def shape(s):
  if type(s)!=unicode: s=s.decode('utf-8')

Brother Hosam! could you please send me the the .py file that
generated your text sample and how can I specify that the dominant
direction of the page is RTL as <body dir="rtl"> in html

From yroman-reportlab at altalang.com  Thu Nov 19 15:33:32 2009
From: yroman-reportlab at altalang.com (Yoann Roman)
Date: Thu, 19 Nov 2009 15:33:32 -0500
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com>
References: <4B054059.1050208@centrivision.com><008c01ca6930$d6e885f0$0502000a@ad.altalang.com><385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com><00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>
	<385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com>
Message-ID: <00d001ca6957$8f7940c0$0502000a@ad.altalang.com>

Muayyad AlSadi wrote...
>> What does your mu.py do differently than Fribidi's Arabic shaping?
> here is the problem,  python fribidi does not do shaping at all,
> that's why we need to pass shaped text to fribidi's log2vis
> 
> fribidi do support shaping but its python binding does not offer that
> see
> http://pyfribidi.sourceforge.net/
> 
> I guess you talk about fribidi_shape
> but pyfribidi only provide fribidi_shape

You need to be using what's referred to as Pyfribidi2, which in turn 
uses Fribidi2. Fribidi2 does shaping as part of the call to log2vis 
unless you specifically ask it not to. A single call to log2vis is all 
we need to get the bidi algorithm and shaping applied when generating 
PDFs in Arabic.

-- 
Yoann Roman


From alsadi at gmail.com  Thu Nov 19 16:27:52 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 19 Nov 2009 23:27:52 +0200
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <00d001ca6957$8f7940c0$0502000a@ad.altalang.com>
References: <4B054059.1050208@centrivision.com>
	<008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
	<385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>
	<00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>
	<385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com>
	<00d001ca6957$8f7940c0$0502000a@ad.altalang.com>
Message-ID: <385866f0911191327g620e2902s590554f74d09dd55@mail.gmail.com>

I'm using fribidi2
rpm -q fribidi
fribidi-0.19.2-1.fc11.i586

the site fribidi.org says that fribidi2 is 0.19 <<EOQ

There is a release of the fribidi2 modules available now, which is
fribidi-0.19.2.tar.gz (md5sum, signed by Behdad Esfahbod) from March
26, 2009. This release is based on Unicode 5.1.0 character database
and is fairly API/ABI compatible with the 0.10 series. The Fedora
project simply upgraded to 0.19 series from 0.10 without any
compatibility issues. Using this version instead of 0.10 series is
highly recommended.

EOQ


so you are suggesting that pyfribidi tells log2vis not todo shaping

I don't see an argument which tells log2vis not todo shapping but
anyway here is the code from pyfribidi

in pyfribidi source here is the call to the log2vis
	if (!fribidi_log2vis (logical, unicode_length, &base_direction, visual,
			      NULL, NULL, NULL))
	{
		PyErr_SetString (PyExc_RuntimeError,
				 "fribidi failed to order string");
		goto cleanup;
	}

From alsadi at gmail.com  Thu Nov 19 16:57:35 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 19 Nov 2009 23:57:35 +0200
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <385866f0911191327g620e2902s590554f74d09dd55@mail.gmail.com>
References: <4B054059.1050208@centrivision.com>
	<008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
	<385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>
	<00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>
	<385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com>
	<00d001ca6957$8f7940c0$0502000a@ad.altalang.com>
	<385866f0911191327g620e2902s590554f74d09dd55@mail.gmail.com>
Message-ID: <385866f0911191357g3eb31f88lbbfe47fe92487d19@mail.gmail.com>

you are right, every thing was solved with pyfribidi2

I've made an rpm for it for fedora 11 / ojuba 3
no need for my mu.py

From yroman-reportlab at altalang.com  Thu Nov 19 16:58:34 2009
From: yroman-reportlab at altalang.com (Yoann Roman)
Date: Thu, 19 Nov 2009 16:58:34 -0500
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <385866f0911191327g620e2902s590554f74d09dd55@mail.gmail.com>
References: <4B054059.1050208@centrivision.com><008c01ca6930$d6e885f0$0502000a@ad.altalang.com><385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com><00ca01ca6951$e9e978a0$0502000a@ad.altalang.com><385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com><00d001ca6957$8f7940c0$0502000a@ad.altalang.com>
	<385866f0911191327g620e2902s590554f74d09dd55@mail.gmail.com>
Message-ID: <00e801ca6963$70a01aa0$0502000a@ad.altalang.com>

Muayyad AlSadi wrote...
> I'm using fribidi2
> rpm -q fribidi
> fribidi-0.19.2-1.fc11.i586
> 
> the site fribidi.org says that fribidi2 is 0.19 <<EOQ
> 
> [snip]
> 
> EOQ
> 
> so you are suggesting that pyfribidi tells log2vis not todo shaping
> 
> I don't see an argument which tells log2vis not todo shapping but
> anyway here is the code from pyfribidi

I'm not sure what to suggest. Using Fribidi 0.19.2 and Pyfribidi 0.8.0, 
I get Arabic shaping automatically when calling log2vis.

-- 
Yoann Roman


From alsadi at gmail.com  Thu Nov 19 16:59:49 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 19 Nov 2009 23:59:49 +0200
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <00e801ca6963$70a01aa0$0502000a@ad.altalang.com>
References: <4B054059.1050208@centrivision.com>
	<008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
	<385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>
	<00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>
	<385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com>
	<00d001ca6957$8f7940c0$0502000a@ad.altalang.com>
	<385866f0911191327g620e2902s590554f74d09dd55@mail.gmail.com>
	<00e801ca6963$70a01aa0$0502000a@ad.altalang.com>
Message-ID: <385866f0911191359n1f73d626t731b01ec9a7156cb@mail.gmail.com>

fedora ships fribidi2 by pyfribidi1 that's why

I'll try to request an update to me rpm

From andy at reportlab.com  Fri Nov 20 05:14:28 2009
From: andy at reportlab.com (Andy Robinson)
Date: Fri, 20 Nov 2009 10:14:28 +0000
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <385866f0911191359n1f73d626t731b01ec9a7156cb@mail.gmail.com>
References: <4B054059.1050208@centrivision.com>
	<008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
	<385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>
	<00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>
	<385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com>
	<00d001ca6957$8f7940c0$0502000a@ad.altalang.com>
	<385866f0911191327g620e2902s590554f74d09dd55@mail.gmail.com>
	<00e801ca6963$70a01aa0$0502000a@ad.altalang.com>
	<385866f0911191359n1f73d626t731b01ec9a7156cb@mail.gmail.com>
Message-ID: <956003ae0911200214l539011f3xfd15af0d9b736a@mail.gmail.com>

2009/11/19 Muayyad AlSadi <alsadi at gmail.com>:
> fedora ships fribidi2 by pyfribidi1 that's why

I'm trying to catch up on this - yesterday was a bit too busy at work
to follow you all.   This library-version stuff all sounds familiar
from when I tried it from source a few months back, but sadly I did
not keep notes.

On ubuntu with just 'sudo apt-get install python-pyfribidi', the test
on the branch runs and produces a page which reverses the order of
glyphs, but does not shape the characters.   Also, I cannot find any
special content in the PDF spec about character shaping, so I guess
the font is supposed

Am I right in understanding that (a) it all works for Yoann, and (b)
we'll need specific instructions on compiling pyfribidi for now, and
will need to get Ubuntu to update their package to make it easy in
future?

Most RL staff run Ubuntu, and if we can get it working in one place,
we can then produce instructions (and binaries if needed) for Win and
Mac.

Thanks,

-- 
Andy

From alsadi at gmail.com  Fri Nov 20 05:57:56 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Fri, 20 Nov 2009 12:57:56 +0200
Subject: [reportlab-users] RTL Patch Committed
In-Reply-To: <956003ae0911200214l539011f3xfd15af0d9b736a@mail.gmail.com>
References: <4B054059.1050208@centrivision.com>
	<008c01ca6930$d6e885f0$0502000a@ad.altalang.com>
	<385866f0911191037w72487b5fvcb430264106f3924@mail.gmail.com>
	<00ca01ca6951$e9e978a0$0502000a@ad.altalang.com>
	<385866f0911191223l734bc19bu6595d4c4edf75e33@mail.gmail.com>
	<00d001ca6957$8f7940c0$0502000a@ad.altalang.com>
	<385866f0911191327g620e2902s590554f74d09dd55@mail.gmail.com>
	<00e801ca6963$70a01aa0$0502000a@ad.altalang.com>
	<385866f0911191359n1f73d626t731b01ec9a7156cb@mail.gmail.com>
	<956003ae0911200214l539011f3xfd15af0d9b736a@mail.gmail.com>
Message-ID: <385866f0911200257j714eb927n735c721fda122428@mail.gmail.com>

> fedora ships fribidi2 by pyfribidi1 that's why
fedora ships fribidi2 but pyfribidi1 that's why

fribidi2 is ABI and APU compatible so fedora calls it fribidi

but the problem is pyfribidi, I made an rpm for pyfribidi2 and called
it pyfribidi