[reportlab-users] Release notes on the website

[Marius Gedminas]

On Thu, May 21, 2009 at 01:35:15PM +0100, Robin Becker wrote:

> Marius Gedminas wrote:

>> So, is the bug

>>

>>  (1) in the font metrics,

>>

>>  (2) in Table layout code,

>>

>> or

>>

>>  (3) in Paragraph drawing code, i.e. the change made in r3192?

>

> It's impossible to say. Because we introduced images in paragraphs  and 

> needed to allow for height adjustments I needed to be more exact about 

> the height above (and below) baseline.


Isn't that orthogonal?  There are two important positions here:

  * the position of the baseline relative to the area allocated
    to the paragraph

  * the position of the image relative to the baseline

I don't see why was it necessary to shift the baseline.  Could you
elaborate?

I tried to produce an example with an in-line <img> tag in the
paragraph.  The output does not look right to me:

  http://mg.pov.lt/reportlab/test-2.3.pdf


> Originally we used Andy's 

> approximation which was

> leading = 1.2*fontSize; where leading is the total distance between 

> consecutive lines(not the size of the lead spacer as in traditional print 

> speak). There was an implicit assumption that leading=ascent+descent and 

> that ascent=fontSize.


Is the goal here to produce output where the ascenders of the characters
touch the top of the area allocated for the paragraph?  Or is the goal
to have the descenders of the characters touch the bottom of the area?

This is the most important question in my email, I think.

ReportLab 2.3 achieves goal (1).  ReportLab 2.1, perhaps accidentally,
used to achieve goal (2):

  http://mg.pov.lt/reportlab/test-2.1.pdf
  http://mg.pov.lt/reportlab/test-2.3.pdf

The files were produced by http://mg.pov.lt/reportlab/paratest.py.

Hm, if leading = ascent + descent, then both goals are the same, aren't
they?  Other than that, I don't quite see how that assumption is
relevant.

Actually, the ascent of the font defines the typical height of capital
letters; accented letters will rise above the ascent (as you can see in
the test-2.3.pdf).  Is that really desirable?


> Clearly the 10pt Times New Roman doesn't come close 

> to that. In the paragraph case we used to work out the height (in 

> lines*leading) and then start the first baseline at top-ascent (ie top - 

> fontSize). If we change our notion of ascent then the first baseline will 

> move.


Hm, yes, I see that.


> Unfortunately nothing prevents people from separately specifying 

> the leading as 12pt so paragraphs appear to shift upwards.


That should be irrelevant, no?  Even if you don't specify the leading
explicitly the paragraphs will appear to shift upwards, as long as
ascent != fontSize.


> On the other hand our table formatting code assumes either 

> flowables(about which it knows nothing) or simple strings which I believe 

> it assumes obey the original leading rule. If the leading rule is wrong 

> then it's wrong in tables as well so probably we ought to fix it there. 


Perhaps.

I think that

  Table([['simple string']], style=...)

and

  Table([[Paragraph('simple string', style=...)]])

ought to produce the same output, assuming the paragraph and table
styles specify the same font face and size, and that the table width is
fixed.  Would you agree with that?

Currently the first one looks well, and the second version looks bad in
ReportLab 2.3.


> That still won't satisfy people who think vertical centred cells should 

> have equal space above and below the text (unless ascent==descent).


So far I hadn't even considered vertically centered cells.  Yay
complications :-)

So far I'm leaning towards the position that ReportLab should not have
changed the position of the baselines within paragraphs in a
backwards-incompatible manner.  Would you accept a patch to shift the
baselines to the old positioning, relative to the paragraph area?  Are
there any use cases where that would result in incorrect rendering?

Marius Gedminas
-- 
Q:  How many IBM CPU's does it take to execute a job?
A:  Four; three to hold it down, and one to rip its head off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20090521/cb86820e/attachment.pgp>