Interesting results if you add the following to your test case:
<fo:block background-color="silver" margin="0pt">
Normal text <fo:inline border="solid 5pt red" padding="5pt"
background-color="white">inline with <fo:block>Blah
blah</fo:block><fo:block>Blah blah</fo:block>border="solid 5pt red"
padding="5pt"</fo:inline> normal finish
</fo:block>
Looks like a little work. The element list generates boxes with height=12000pt
for each of the nested blocks (which seems to be correct), but the
renderer increases the currentBPPosition by (2 * (5pt + 5pt)) after
painting the inlineblockparents. So there is definitely something wrong
with the renderers, too. We probably need to teach them the difference
between the normal-allocation-rectangle and the
large-allocation-rectangle.
On 02.09.2005 08:37:06 Jeremias Maerki wrote:
> The place to start is certainly the InlineLayoutManager. It looks like
> the width of the inline is reported correctly through the KnuthElements,
> but there is either a problem in addAreas or in the renderers that the
> content of the inline is not indented in i-p-d. Check getExtraIPD()
> which doesn't seem to be referenced. This could indicate something. The
> other problem is the b-p-d. Since fo:inline uses the
> normal-allocation-rectangle (I've check this time), the KnuthElements
> seem fine concerning the size they report. As with i-p-d I can imagine
> that there is a problem with the renderers about painting inlines. The
> "bpda" of the inlineparent area looks correct to me but it's not painted
> that way. I think this should all be easily fixable.
>
> The real problem IMO is probably block-level content in fo:inlines again.
> How are these borders to be painted? A border around each
> inlineblockparent (one for each block inside the inline)? I'm not sure
> judging from the specification.
>
> HTH
>
> On 02.09.2005 07:21:49 Manuel Mall wrote:
> > Vincent, Jeremias,
> >
> > thanks for the clarification.
> >
> > After looking just a little bit more into it it appears the current fop
> > version is dealing pretty badly with inline borders and padding. There
> > seem to be no testcases for it either.
> >
> > I'll attach 2 files.
> > A simple test case.
> > The pdf output from that as produced by the current trunk version.
> >
> > The output is wrong on a number of points.
> > 1. The border / padding is overlapping with the text
> > 2. The top/bottom border / padding should be outside the allocation
> > rectangle for the fo:inline and therefore extend above and below the
> > enclosing block.
> > 3. There is a strange gap between the fo:inline and the following
> > text. I suspect it has to do with some piece of code using the correct
> > allocation rectangle and others not.
> >
> > Not sure if I am up to fixing this as that may go into the depth of the
> > Knuth boxes etc.. But if someone if prepared to give me some pointers
> > on where to start I'll be prepared to give it a go.
> >
> > Manuel
> > On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote:
> > > Oh right. Again someone caught me shooting too fast from the hip.
> > > Damn. I will probably never manage to get that right. :-( It's good
> > > to have people around to pay attention.
> > >
> > > I wondered about the large-allocation-rectangle while reading through
> > > 6.3.2 but obviously forgot to check the docs for e-g and i-f-o.
> > > Sorry, Manuel, Vincent is right.
> > >
> > > On 01.09.2005 18:44:52 Vincent Hennebert wrote:
> > > > I'm not sure here. The fo:external-graphic uses the
> > > > large-allocation-rectangle (§ 6.6.5), that comprises padding and
> > > > border. This makes me say that in Manuel's example the fo:block's
> > > > bpd should be calculated with the second formula. The fo:block's
> > > > content forms a line whose line-stacking-strategy is max-height
> > > > (default). Thus its allocation rectangle should comprise the
> > > > image's border & padding (§ 4.5). And so does the block.
> > > >
> > > > I may be wrong, as this part of the spec is still somewhat unclear
> > > > to me. WDYT?
> > > >
> > > > Vincent
> > > >
> > > > Jeremias Maerki a écrit :
> > > > > Indeed, the normal allocation rectangle of an inline area is
> > > > > different than the one of a block area. See 4.3.2. Geometric
> > > > > Definitions in the 1.0 spec.
> > > > >
> > > > > Border and padding for an inline area seem to be outside the
> > > > > allocation rectangle in before and after directions. Interesting.
> > > > >
> > > > > On 01.09.2005 17:29:50 Manuel Mall wrote:
> > > > >>I have a follow-up question on this. If we have something as
> > > > >> simple(?) as this:
> > > > >>
> > > > >><fo:block background-color="orange">
> > > > >> <fo:external-graphic
> > > > >> src="../../resources/images/bgimg300dpi.jpg"
> > > > >> border="solid 5pt"
> > > > >> padding="5pt"
> > > > >> background-color="white"/>
> > > > >></fo:block>
> > > > >>
> > > > >>would you expect the whole image including padding and borders to
> > > > >> be within the bounds of the enclosing block or only the actual
> > > > >> image to be in the block and the padding and borders to "stick
> > > > >> out" at the top and bottom. It seems xep takes the latter
> > > > >> approach and I am very uncertain in this area. Or to put it
> > > > >> differently is the BPD of the enclosing block
> > > > >> bpd = image height + line-spacing
> > > > >>or
> > > > >> bpd = image-height + top_and_bottom_borders +
> > > > >> top_and_bottom_padding + line-spacing
> > > > >>?
> > > > >>
> > > > >>Manuel
> > > > >><snip/>
> > > > >
> > > > > Jeremias Maerki
> > >
> > > Jeremias Maerki
>
>
>
> Jeremias Maerki
Jeremias Maerki
