Re: Tried reportlab on python 3.4... failed

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
-- 
Jim's Three Laws of Engineering:
  1. F = ma
  2. You can't solve a problem unless you know the answer
  3. You can't push a rope

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iD8DBQFUTTsHkVdEXeem148RApwBAKCQo0fiUoDiL94qtFH35rMSZGzL9ACeKh9b
lNJuAvQqbumHO7bCRU/TpTs=
=JtsD
-----END PGP SIGNATURE-----