You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Scott Carlson <Sc...@yahoo.com> on 2000/10/27 01:02:49 UTC

Line-Height (Leading) problem...

I'm hoping someone can explain the current behavior for leading in FOP.

If you review the way the code works. BlockArea.addLineArea() adds
halfLeading for the block, which I would guess is for the descender.  Then
adds the area for the height of the area, for the character.  Then adds the
halfLeading again.

The problem is that this means the numbers don't add up.  The actual space
allocated for a line is equal to  GlyphHeight + Entered Line Height - Font
size.  Or another way to look at it, to get a line height of close to what
you really want add this.fontSize - (getAscender()-getDescender()) to the
desired line-height.  I derived these values from the LineArea() constuctor.

This appears to have existed since version 1.1, so I guess no one else has
need the precision that we do.

Another way to visualize the problem, not to scale of course, is to think
about two consecutive lines.
If the first line is a different leading or font-size than the second, than
the space between the baselines is (halfLeading for 9pt/10pt font) +
(GlyphHeight + halfLeading for 8/9pt font)
------------------------
halfLeading |
GlyphHeight | word 9pt/10pt leading
halfLeading |
------------------------
------------------------
halfLeading |
GlyphHeight | word 8pt/9pt leading
halfLeading |
------------------------

Has anyone else had these problems?   Does anyone know why it is this way?

Scott Carlson
ScottCarlson_yahoo_com