[reportlab-users] Tried reportlab on python 3.4... failed

[Glenn Linderman]

On 10/26/2014 11:18 AM, Marius Gedminas wrote:
> On Sat, Oct 25, 2014 at 11:07:39PM -0700, Glenn Linderman wrote:
>> On 10/25/2014 7:16 PM, Andy Robinson wrote:
>>> Hi Glenn,
>>>
>>> As far as we know the code behaves identically in Pythons 2.7, 3.3 and
>>> 3.4; certainly the user guide generates and all the tests run.
>> Thanks, Andy, your suggestions certainly look more practical than the user
>> guide code, so I reworked  the code in the manner you suggest (although your
>> styBase omits the name parameter, in case someone else uses this as a
>> reference), and got it to work, no longer needing to deal with endDot or
>> splitLongWords... or quite a few others.
>>
>> However, in running the new code on an old file, it seems there may have
>> been a change to the way image sizes are determined to fit or not, within a
>> frame.
>>
>> I don't recall how I figured out what image size (maybe from the error
>> message I got then) was maximum when I set this up, but I was trying to fill
>> the frame, and did... but now I get an error that the image is too big, but
>> the image hasn't changed, nor has the frame size, unless this altered
>> technique somehow changes it.
>>
>> reportlab.platypus.doctemplate.LayoutError: Flowable <Image at 0x32f0b70
>> frame=normal filename=...\front.jpg>(197.76 x 197.76) too large on page 2 in
>> frame 'normal'(186.0 x 186.0*) of template 'Later'
>>
>> To obtain another data point, I used the new code, but the old python 2.7
>> and reportlab 2.5, and the image size was accepted. So it may be that the
>> _current_ code behaves identically on Python 2.7, 3.3, and 3.4 (I don't have
>> all the combinations installed), but the current reportlab code on Python
>> 3.4 seems to behave differently than reportlab 2.5 on Python 2.7 regarding
>> image and frame sizes.
>>
>> The release notes on your site only go back to 2.7, so I can't say if 2.6
>> specifically called out changes in this area, but I would assume that
>> "minor" fixes not completely described in the release notes that are on the
>> site wouldn't include significant changes to the image and frame size
>> calculations.
>>
>> I do note the switch from PIL to PILLOW but have no idea if that would
>> affect the sizes: since both PIL and PILLOW deal in bitmaps, I would doubt
>> it.
>>
>> Any clues?
>>
>> Here are some more details:
>>
>> The actual image size is 412x412, and the resolution in the jpg file is
>> 300dpi.
>> The page size (small booklet) is 3.25"x3.25", with .25" margins all around.
>>
>> Here is the code the positions the image on the page:
>>
>>          res = 150
>>          page.do( False )
>>          im = Image( img, theCovWid/res*inch, theCovHei/res*inch )
> I think you tripped the Python 3 change to the / operator:
>
>      $ python2
>      >>> 412/150
>      2
>
>      $ python3
>      >>> 412/150
>      2.7466666666666666
>
> If you want to round down like the code used to in Python 2, use the //
> operator:
>
>      $ python3
>      >>> 412//150
>      2
>
> i.e.
>            im = Image( img, theCovWid//res*inch, theCovHei//res*inch )
>
> (which seems to be a bug in your old code, that went unnoticed for a
> long time -- you're effectively using a resolution of 206 dpi instead of
> 150 dpi -- but if you use the right resolution, your image doesn't fit!)
>
>>          im.hAlign = 'CENTER'
>>          im.vAlign = 'CENTER'
>>          elements.append( im )
>>          page.do( True )
>>
>> theCovWid and theCovHei are both 412.
>>
>> When I calculate 3.25" - 2*.25 * 150, I get 412.5 which is only slightly
>> larger than 412, and it works in rl2.5/Py2.7.
>>
>> I have no idea where 197.76 or 186.0 come from.
> So assuming theCovWin == 412, res == 150, inch == 72
>
> On Python 3 you get 412/150*72 == 197.76, which doesn't fit in the frame
> that is 186 points wide.
>
> On Python 2 you get 412/150*72 == 144, which fits in the 186-point
> frame.
>
>> Maybe that is in mm?  Hmm.
>> Nope. 2.75" == 69.85mm. Ah, maybe points... 2.75" = 198pt. Unless you use a
>> point size other than 72/inch.
> PDF points are 1/72 inch, yes.
>
>> Anyway this is pretty close. Assuming 186.0
>> is in the same units... that would be 2.58333"... the difference being about
>> 12 points or 6 points a side if it is some sort of padding or margin, which
>> seems likely, since it has affected both height and width calculations.
>>
>> The documented defaults for all those sorts of things seem to be zero,
>> rather than 6pts, however.
> HTH,
> Marius Gedminas

Thanks, Marius, this explains what is actually happening, no doubt. Your 
numbers all add up. One remaining confusion on my part, though, is where 
does the 186 point frame come from?

( 3.25 - 2*.25 )in * 72pt/in = 198pt

So while I clearly didn't do the calculation correctly (in Py2 I should 
have done theCovWid*inch/res for more accuracy, that results in 197 on 
Py2 and 197.76 on Py3 due to the / change), either of those numbers 
seems to be smaller than, but closer to, the 198pt frame size I thought 
I was targeting (but I was thinking in inches and pixels rather than 
points). So is there some implicit padding or margin that produces the 
186pt frame size mentioned in the error message? Sans my inaccurate 
calculation and failure to actually measure the results with a ruler, I 
would have asked about this when I wrote the Py2 version of my program! 
But that being my first reportlab program (and few others since, since 
it required the use of Py2, which is awkward for me, having chosen Py3 
for my first forays into Python, I might use it more now that it works 
with Py3) I was pretty vague on how the calculations were done or what 
they meant, but the one I used fit my (apparently faulty, even still) 
mental model of how the sizes worked.

Your message, of course, leads me directly to a solution for producing 
the same output as I was before, but doesn't fully explain where the 
186pt frame size comes from.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20141027/86d75214/attachment.html>