Hi Arved (and other interested parties),
Lots of other bugs (like the inline-area height) show up well in tables
because the grid makes things visible. That's the case with the trailing
white-space bug I saw the other day, resulting in an empty table row.
Some of these can also be shown by using
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
At 12:22 AM 8/6/01 +0200, Karen Lease wrote:
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
Arved Sandstrom wrote:
At 12:22 AM 8/6/01 +0200, Karen Lease wrote:
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
Hi, Karen (and other interested parties)
A thought occurred to me just now. A high percentage of our bandwidth (and
bug reports) are devoted to tables. There are so many table-related bug
reports mainly because so many folks want to use tables, I believe, not
because there are more bugs in
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
