[reportlab-users] Ascent, descent and tables

[Marius Gedminas]

On Thu, May 21, 2009 at 05:23:53PM +0100, Andy Robinson wrote:

> Marius, thanks for bringing this up, and producing examples.   At

> various points in the last 2 years I have briefly half-understood this

> issue, then forgotten it again.  We made necessary "improvements" to

> paragraphs to support inline images and equations for Wikipedia and to

> adjust inter-line heights within paragraphs,


That sounds *awesome*!


> but it seems that in the

> process we are now reporting a bounding box for the paragraph that

> extends too far down.


Do you still use leading_as_specified_in_style_* number_of_lines for the
bounding box?

I'm staring at the code here, and wondering about the autoLeading
setting.  Shouldn't (l.ascent - l.descent) be more or less equivalent to
fontSize rather than leading?  I'm not a typography expert, but e.g.

  Type is typically measured in points, and type size is referred to as
  point size. (Point size is determined by measuring from the top of the
  highest ascender to the bottom of the lowest descender, and therefore
  cannot be accurately measured from a single character.)

 -- http://ilovetypography.com/2008/04/25/extreme-type-terminology-part-4/

On the other hand I've also seen explanations saying that the font size
nowadays is an arbitrary number, not necessarily related to the font's
physical features.

Nevertheless, for the built-in Times-Roman at 10pt I if I calcualte
ascent-descent I get 9pt, while for Times New Roman the difference is
9.1pt.  Leading shouldn't be smaller than the font size, should it?

By the way,
http://ilovetypography.com/2008/04/11/extreme-type-terminology-part-3/
has a very nice diagram about ascenders/descenders/etc.  Before I read
that post I had no idea there was a difference between ascent and
ascender line (one is the cap height, the other is the ascender height,
and they may be different).

Also note that when you get accented capital letters such as ČŽŠĖÜ, the
diacritics will be above the ascender line.


> I amended test_platypus_tables.py which now produces the attached PDF.

>  I also added a pink background so you can see the boundary reported

> by the paragraph.  The paragraph claims to be using a chunk of space

> beneath the lowest descender.


Yes.


> (BTW, before the change, the paragraphs used to claim to be using

> extra space ABOVE the highest extender, because of the approximation

> Robin refers to).


Which is correct if you have diacritics, isn't it?

I'm very aware of diacritics above capital letters since Lithuanian has
them. ;-)


> We will try to change things so that (a) paragraphs report their

> bounding box as precisely as possible, and tables can then center this

> box vertically; and (b) paragraphs try to position naked text the same

> way they would position a one-line paragraph with the same font size

> and "leading".   This might take a few days, and we will also need to

> look at preformatted blocks and labels in charts.


Thank you!  Though I have some reservations about that, see below.


> If anyone knows of other problems not covered by this test case,

> please let me know...


To look good, the spacing between the top of the table cell and the
ascender line should be the same or smaller than the spacing between the
bottom of the table cell and the *baseline*.

If you compute the bounds accurately, you'll have the top spacing match
the spacing between the bottom of the table cell and the descender line,
which will not look good.

Because of this (and, to some lower extent, because of diacritics that
may appear above the ascender line), I think it is correct for
Paragraphs to claim a little extra space above the ascender line.

I see two reasonable options for that extra space:

  * Claim abs(descent), i.e. the same amount as descenders currently do.
    This will give you perfect vertical centering inside table cells.

  * Claim (fontSize - ascent), which will position the baseline
    precisely fontSize points below the top of the area.  This will
    restore backwards-compatibility with ReportLab versions prior to
    2.2.

Marius Gedminas
-- 
(ಠಿ_ಠಿ)
-------------- 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/bf04ab58/attachment-0001.pgp>