Allright, I will have a go at this and scream for help if I get stuck. 
Step 1 would be to get the area tree right and step 2 would be to make 
any required adjustments to the renderers. This means I will learn more 
about layout and rendering at the same time (need to have a positive 
angle to this).

Manuel

On Fri, 2 Sep 2005 02:44 pm, Jeremias Maerki wrote:
> 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

Reply via email to