At 06:53 PM 8/7/01 +0200, you wrote:
>Koen (and Ralph and others),
>There is a problem, but it's not a border-drawing problem.
Sorry, I wasn't clear -- I'm suggesting there are ~two~ separate problems
here. The first is what you describe below. The second is: given
the fo such as it is, it renders differently for -print and -awt versus
-pdf. On both -awt and -print no border is drawn for the table cells.
The pdf renderer ~does~ draw the table borders.
The awt/print problem is due to AWTRenderer attmpting to fill a rectangle
with either the width or height of zero. This happens when the border size
drops below a threshold (i.e., 500 millipts) This all stems from a patch
to AWTRender I supplied a few weeks ago in which, among other things, we
made AWTRenderer honor actual border sizes.
(The original 0.19.0 AWTRenderer drew ~all~ borders 1 pixel thick,
regardless of border-size.)
Does this make sense to you ? If so, I supplied a patch earlier today to
>You have a left-margin specified as 2cm on a block which is containing
>the paragraphs before the table and the table itself. This property is
>inherited and is therefore used on both the fo:table and the fo:blocks
>inside the fo:table-cell objects.
>What isn't normal is that the table itself should be indented by 2cm and
>it isn't. But that in itself won't fix the cell text alignment, since
>the margin (or start-indent which is the same thing) is being inherited
>by all the content inside the table. So the cell content would still be
>Assuming that FOP handled indent correctly on the table, you would want
>to set it back to a smaller value, on table-body for example.
>In the meantime, there is an ugly workaround involving an empty first
>column whose width is equal to the current indent and which only has
>borders on the right side.
>As Arved has just suggested focusing on tables, this problem will be a
>good place to start and I'll try to put it on the high priority list.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]