You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by j1997 <mh...@gmx.de> on 2008/10/02 15:54:16 UTC

Upgrade 0.20.5 to 0.95: all texts are shifted to top!

After upgrading to FOP 0.95, all texts (in table cells) are shifted towards
the top (the table cell's top border). It looks like the old FOP 0.20.5
centered the text in a cell by the capital letters (i.e. a capital letter is
exactly vertically centered) and the new FOP 0.95 centers text vertically by
the lower letters. Resulting in all texts being shifted upwards. I found a
workaround by inlining each text:

                      <fo:inline alignment-adjust="central"> 
                          <xsl:value-of select="."/> 
                      </fo:inline> 

Then, the text looks like in the old FOP 0.20.5: it's vertically centered by
the capital letters. Of course, this is an ugly workaround and there's
probably a global setting for this. But why does FOP 0.95 do this? And how
can I change it at one (single) place - and not for each text in table cell?
-- 
View this message in context: http://www.nabble.com/Upgrade-0.20.5-to-0.95%3A-all-texts-are-shifted-to-top%21-tp19779752p19779752.html
Sent from the FOP - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Upgrade 0.20.5 to 0.95: all texts are shifted to top!

Posted by Vincent Hennebert <vh...@gmail.com>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Upgrade 0.20.5 to 0.95: all texts are shifted to top!

Posted by j1997 <mh...@gmx.de>.

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. :-(
-- 
View this message in context: http://www.nabble.com/Upgrade-0.20.5-to-0.95%3A-all-texts-are-shifted-to-top%21-tp19779752p19834943.html
Sent from the FOP - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Upgrade 0.20.5 to 0.95: all texts are shifted to top!

Posted by Andreas Delmelle <an...@telenet.be>.
On Oct 3, 2008, at 12:23, Vincent Hennebert wrote:

> <snip />
>> Resulting in all texts being shifted upwards. I found a
>> workaround by inlining each text:
>>
>>                       <fo:inline alignment-adjust="central">
>>                           <xsl:value-of select="."/>
>>                       </fo:inline>
>
> Not sure there is any other workaround, I’m afraid. If text-depth were
> implemented you could use that, although that would also require to
> tweak your stylesheet anyway. Maybe some particular value of the
> line-stacking-strategy property may do the job, but this property
> remains cryptic to me.

FWIW: I don't think this property will really solve anything. "line- 
stacking-strategy" tells the formatter how the lines in a given block  
are to be stacked, or IOW, which height will be used for each line- 
area. For a value of "max-height", the actual line-height can vary  
for each line, depending on the content. (in the Recommendation's  
terms: each line will use the 'maximum-line-rectangle') So, if an  
image appears in the line, and the image is larger than the largest  
glyph, then the line will be as high as that image (plus half-leading).
For a value of "font-height", the lines for a given block will all  
have the same actual height, which depends on the font(-size) of the  
block in question (in the Recommendation's terms: each line will use  
the 'nominal-requested-line-rectangle'). Result is that the same  
image would now overflow the previous or next line(s), since it does  
not fit. Analogous reasoning for nested inlines or wrappers with a  
different font or simply a larger font-size than the block.

FOP currently offers support for those two values: max-height and  
font-height. The value of line-height is not supported. I haven't  
checked yet whether FOP follows the Recommendation here, and does the  
same for line-height as it does for max-height.

What you can do, by specifying "font-height", is make sure that the  
lines in cell 1.1 are always exactly the same height as in cell 1.2,  
with the described side-effect for embedded text in a larger font(- 
size) or larger images.


Cheers

Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Upgrade 0.20.5 to 0.95: all texts are shifted to top!

Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,

j1997 wrote:
> After upgrading to FOP 0.95, all texts (in table cells) are shifted towards
> the top (the table cell's top border). It looks like the old FOP 0.20.5
> centered the text in a cell by the capital letters (i.e. a capital letter is
> exactly vertically centered) and the new FOP 0.95 centers text vertically by
> the lower letters.

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

> Resulting in all texts being shifted upwards. I found a
> workaround by inlining each text:
> 
>                       <fo:inline alignment-adjust="central"> 
>                           <xsl:value-of select="."/> 
>                       </fo:inline> 

Not sure there is any other workaround, I’m afraid. If text-depth were
implemented you could use that, although that would also require to
tweak your stylesheet anyway. Maybe some particular value of the
line-stacking-strategy property may do the job, but this property
remains cryptic to me.


> Then, the text looks like in the old FOP 0.20.5: it's vertically centered by
> the capital letters. Of course, this is an ugly workaround and there's
> probably a global setting for this. But why does FOP 0.95 do this? And how
> can I change it at one (single) place - and not for each text in table cell?


If that doesn’t really help, I hope this clarified FOP’s behaviour.
Vincent

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org