From marius at gedmin.as  Thu Dec 12 06:48:33 2024
From: marius at gedmin.as (Marius Gedminas)
Date: Thu, 12 Dec 2024 13:48:33 +0200
Subject: [reportlab-users] Vertical table alignment change in ReportLab
 3.5.44
Message-ID: <fnq6hkav7zkfgsomj7qwfs5oriqtxpr2tfsh7agb6el2ko2nlc@3ted4n2iynd2>

Hello!

While updating dependencies of old application that was still using
ReportLab 3.5.23 I noticed a strange change in behavior with vertical
table alignment.  I've narrowed it down to a change between ReportLab
3.5.42 and 3.5.44 with the following code:

  https://gist.github.com/mgedmin/079923e0c115ce88db8a56496a9a3b92

The leftmost table cell that contains the 'A' is vertically aligned at
the top, like the table style requests in 3.5.42, but suddenly gets
aligned at the bottom with 3.5.44 and newer versions.  (You can see
screenshots of the two versions of the PDF in the comments below the
gist itself.)

Does anyone know what's happening there?  Have I found a bug?

I'm attaching the code for completeness, in case accessing the gist is
inconvenient.

(BTW I've been away for a long time.  Do you perhaps have a Git
repository available somewhere?)

Regards,
Marius Gedminas
-- 
<mcdonc> i'm going to start charging by the facepalm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reportlab_table_bug.py
Type: text/x-python
Size: 2797 bytes
Desc: not available
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20241212/072820ed/attachment.py>

From robin at reportlab.com  Thu Dec 12 11:39:09 2024
From: robin at reportlab.com (Robin Becker)
Date: Thu, 12 Dec 2024 16:39:09 +0000
Subject: [reportlab-users] Vertical table alignment change in ReportLab
 3.5.44
In-Reply-To: <ooqbxz6e2utchkdkhcssheo5d2ve22uvtg46l3ibapf5pab2rv@sfsysuqxnkyp>
References: <fnq6hkav7zkfgsomj7qwfs5oriqtxpr2tfsh7agb6el2ko2nlc@3ted4n2iynd2>
 <6a555293-14d7-4574-aca8-75f783e03aec@everest.reportlab.co.uk>
 <ooqbxz6e2utchkdkhcssheo5d2ve22uvtg46l3ibapf5pab2rv@sfsysuqxnkyp>
Message-ID: <b8669a6d-e088-40e4-be5c-b2911bea9973@everest.reportlab.co.uk>

Hi Marius,

I think I found the problem cause using this code

if __name__=='__main__':
	import os
	from reportlab import Version as rlVersion
	from subprocess import check_output
	hgidnum = check_output(["hg", "id", "--num"]).decode('ascii').strip()
	from reportlab.pdfgen.canvas import Canvas
	from reportlab.lib.styles import ParagraphStyle
	from reportlab.platypus.paragraph import Paragraph
	from reportlab.lib.enums import TA_CENTER, TA_JUSTIFY, TA_LEFT
	from reportlab.pdfbase.pdfmetrics import stringWidth
	sty = ParagraphStyle('normal',firstLineIndent=0,spaceBefore=6,fontSize=10,alignment=TA_LEFT)
	txt = os.environ.get('A','A')
	p = Paragraph(f'<font color="0xff0000">{txt}</font>', sty)
	slen = stringWidth(txt,sty.fontName,sty.fontSize)
	aW = float(os.environ.get('aW','4'))
	aH = 71994
	canv = Canvas('dummy.pdf')
	w, h = p.wrapOn(canv, aW, aH)
	print(f'reportlab.Version={rlVersion} hg id --num={hgidnum} len({txt=})={slen} p.wrapOn(canv,{aW=},{aH=}) --> {w=} {h=}')


It seems that your first column width was too small. In rev >= 4587 I see these results

> $ aW=6.67 python devel/tparah.py 
> reportlab.Version=3.5.43 hg id --num=4587 len(txt='A')=6.67 p.wrapOn(canv,aW=6.67,aH=71994) --> w=6.67 h=12

if we reduce the available width then the paragraph wants to wrap to the next line and gives a height that is too large

> $ aW=6.66 python devel/tparah.py 
> reportlab.Version=3.5.43 hg id --num=4587 len(txt='A')=6.67 p.wrapOn(canv,aW=6.66,aH=71994) --> w=6.66 h=24

we cannot split the single 'A' so it seems we have an issue with the reported height and the actual drawing.

Probably the Paragraph height computation needs looking at at least for this specific case where it seems the wrap 
height differs from the drawn height.
-- 
Robin Becker