[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