[reportlab-users] Couple bugs in 2.0
    Boris Borcic 
    bborcic at gmail.com
       
    Tue Apr 10 04:47:30 EDT 2007
    
    
  
Hello,
Just thought I should report the couple bugs/workarounds I needed to use rl 2.0 
(still present in trunk).
First, I made a text object subclass whose instances sync their cursors, what 
lead me to notice that the internal model of the cursor position of text objects 
was updated with an y-value opposite to that actually used by eg. Acrobat to 
render the text; at least when the coordinate system is the default "bottom up".
My solution was to modify line 196 of textobject.py in PDFTextObject.moveCursor
         self._code.append('%s Td' % fp_str(dx, -dy))
by deleting the minus sign before the dy. My *guess* is that text cursor 
coordinates are seldom polled so that the discrepancy went unnoticed while the 
(suspicious) minus sign probably came about as a (overly quick) fix in another 
context (bound to be broken by my (reverting?) change). (What makes the sign 
suspicious is that there is no reason to have the y coordinate treated 
differently from the x, is there ?).
My cursor-syncing textobject subclass bypasses the cursor motion aggregation 
logic of lines 171 to 190 of the same file and method (by using python variables 
rather than pdf code to store the last motion and generating pdf code for the 
motion only when some text actually gets written); but it seems obvious that 
line 184 would need to be updated with a coordinated sign change.
The second buglet I found is that normalDate.setNormalDate accepts strings but 
not equivalent unicode.
Best regards,
Boris Borcic
    
    
More information about the reportlab-users
mailing list