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
