Hi Peter,

Thanks for the test files. Yes, you are right that font metrics
influence the calculation. In fact, these examples point out a number of
problems with FOP's line sizing logic. The sizing is really determined
by the font-family and font-size specified or inherited on the fo:block
containing the text. The actual size of the text is ignored in
calculating the line height! So the last four lines of your table
correspond to this:

1. 18pt, Arial
2. 18pt,  default font-family (sans-serif)
3. default font-size (12pt), Arial
4. default font-size (12pt), default font-family (sans-serif)

The font metrics for Arial obviously have a larger ascender value than
those for the default font.

So much for the explanations. Unfortunately, I'm not sure I'll try to
fix this right away, since I fear that it involves some rather major
changes. It really comes down to the fact that the fo:inline object
doesn't actually generate a nested inline area, but just adds characters
to the LineArea. So there's no place for it to actually store the
line-height information. Perhaps someone else will be be braver. In any
case, it's certainly on the list for the layout redesign...

Regards,
Karen

Petr Andrs wrote:
> 
> Hi Karen,
> 
> I have made some further investigation. I agree that this is probably
> not specific to tables, but it is better observable on tables. When
> using embedded TTF fonts, height of line is influenced also by font-
> family attribute. If font-family is specified on table-row or cell (I
> think it can be generalized to any block level object) height of line
> is different from case when font-family is specified on inline level
> object. So I made simple testing example. I made table with lines
> having all possible combinations of place of specificatin of font-size
> and font-family (at block level v. at inline level) resulting in four
> table lines. Then I made more combinations using two different font-
> sizes and two different font-families resulting in 16 line table.
> Results of this experiment are attached. You can notice than every line
> printed by Arial 18pt (the four bottom lines) has its own unique height
> of line. So it maybe has something to do with usage of font metrics.
> 
> Petr
> 
> On 5 Aug 2001, at 0:16 Karen Lease wrote about Re: problems with height of cells i :
> 
> > Hi Petr,
> >
> > I've looked at this quickly and my first reaction is that it's probably
> > not specific to tables. I think it has to do with line-height (aka
> > leading in old typographic terms). Neither font-size nor line-height are
> > specified at a high level in your .fo. The default font-size is 12pt and
> > the default line-height 1.2 em (14.4pt). When you set font-size at the
> > block level as in the last row, that will also change the line-height,
> > since it's relative, so the total height is smaller. When you set
> > font-size at the inline or wrapper, it apparently isn't changing
> > line-height. I guess since line-height can be specified for both
> > fo:ineline and fo:character (via the fo:wrapper), that the line-height
> > should also be modified by setting font-size on those objects too.
> >
> > Good eye!
> 
> on thousand lines the difference makes several pages so it is quite
> noticable
> 
> > Regards,
> > Karen
> >
> > Petr Andrs wrote:
> > >
> > > Please see attached file. There is table with three lines, which all
> > > should have equal height. But they haven't, the last one has lower
> > > height than the other two. (Or the fist two have greater height than
> > > the las one) I would expect all three lines to look something like the
> > > last one, the first two are too high for my eye.
> > >
> > > Petr
> 
>   ------------------------------------------------------------------------
>                  Name: emptest.fo
>    emptest.fo    Type: unspecified type (Application/Octet-stream)
>              Encoding: BASE64
> 
>                   Name: emptest.pdf
>    emptest.pdf    Type: Portable Document Format (application/pdf)
>               Encoding: BASE64
> 
>   ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to