[reportlab-users] question re: paragraph bounding box vertical offset

[Matt Folwell]

On 01/09/2010 01:24, Chris Jerdonek wrote:

> 

> Thanks for the response, Matt.

> 

> Can you elaborate on the disadvantage of setting paraFontSizeHeightOffset = 0?

> 


Try running the attached script, which produces 2 PDFs, one with each
setting.  It contains a table with strings in the left column and
Paragraphs in the right, with the same font, size and leading.

I'd expect the baselines of the text in the two columns to at the same
height, especially as I often change my mind about whether to use a
string or a Paragraph, and I want to change without it changing the
layout.  Also if you use different fonts at the same size, setting
paraFontSizeHeightOffset = 0 will make them have different baselines.


There was also some discussion on this list when ReportLab 2.3 was
released, starting from here:
http://two.pairlist.net/pipermail/reportlab-users/2009-May/008260.html



> The default of setting it to 1 seems to have its own disadvantage:

> 

> For example, if you create a table with a single cell that contains a

> Paragraph with one line of text, the paragraph text can protrude past

> the bottom border of the table cell (even with positive border

> padding).  This is because of the observations above and the fact that

> a table cell seems to care only about bounding a paragraph's bounding

> box and not its text.  Setting it to 0 ensures that the paragraph text

> stays inside the paragraph's bounding box -- and so inside any

> containing table cell.

> 


This isn't a problem if you (a) use adequate leading on your paragraphs,
or (b) use bottompadding in your table cells. I usually have to adjust
table padding by eye anyway, so it's no extra trouble to make sure
there's enough to keep the paragraph text inside the cell.

Matt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: paraFontSizeHeightOffset.py
Url: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20100901/764cd38a/attachment.ksh>