Hi,
There is another workaround that may be more acceptable for you, but you
need to know the metrics of the font you’re using. Here I will refer to
the Nimbus Sans L font, which is a libre clone of Helvetica and has the
advantage of providing a human-readable afm metrics file.
The descender value of this font (how far the ‘p’ letter, and usually
any letter with a descender, hangs below the baseline) is -218. This
means that for a text size of 1pt, letters with descenders will hang
218 millipoints below the baseline.
In your case your text contains no letters with descenders; so this is
as if you had an additional padding below the text of 218*(font
size) mpt. To compensate you just have to set a padding-top of the same
size on the table-cell. So if the text size is 10pt you have to specify
a padding-top of 2.18pt. Then your numbers will visually look centered.
You can semi-automatize the process by using inherited-property-value:
<fo:table-cell
padding-top="inherited-property-value(font-size) * 0.218">
<fo:block>ToDo</fo:block>
</fo:table-cell>
This will effectively increase the height of the cell; if you don’t want
that you may instead specify a negative margin on the block inside the
cell:
<fo:table-cell border="1pt solid black">
<fo:block space-after="-2.18pt"
space-after.conditionality="retain">ToDo</fo:block>
</fo:table-cell>
But this is more tricky to setup properly.
This will usually work fine provided that the descender value specified
in the font metrics is accurate. This works with Nimbus Sans L but may
not for other fonts! Your mileage may vary.
HTH,
Vincent
j1997 wrote:
>
> Vincent Hennebert-2 wrote:
>> I guess FOP 0.20.5 was taking the height of the biggest letter for the
>> line height, which is wrong; what’s supposed to happen if you put a word
>> like ‘jaguar’ in one cell, and ‘ToDo’ in the next cell? Should the
>> baselines be aligned or not?
>>
>> Details can be found in section 4.5 of the XSL-FO specification [1] (who
>> said this section was scary?). In short, the line height is the sum of
>> text-altitude and text-depth [2]. Those are taken from the font metrics
>> and are general (i.e., apply to every glyph, even those that don’t hang
>> below the baseline). So the effect is what you noticed: if a word
>> doesn’t have any letter with a descender, it will look like it’s
>> shifted, whereas technically speaking it’s not.
>>
>> [1] http://www.w3.org/TR/xsl11/#area-line
>> [2] http://www.w3.org/TR/xsl11/#text-depth
>>
>
> I did some more testing and the result is, that the new FOP 0.95 always has
> the same result:
>
> <fo:block text-align="start" font-family="{$Font}"
> font-size="20pt" color="{$TitleFontColor}">
> <xsl:text>geeeeeeeeeeeeeeeeee</xsl:text>
> </fo:block>
>
> No matter if I only set capital letters or only small caps, only "gjy" or
> with/without paranthesis, all examples have the same result, i.e. a letter
> is always placed at the same horizontal position - no matter if/what other
> letters are in the same line/block. In my example font, the text is always
> displayed that an "e" is exactly horizontal centered.
>
> As you might argue, that it's more "correct" to center the small letters
> like "e", it looks really awkward if a line/block only has a number, because
> the digits are also "shifted upwards".
>
>
> In addition, with the fo:inline "workaround", the whole line/block gets a
> bigger height. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
