Had a look at this problem (fo:inline with border and padding) and have 
a question regarding the "contract" between the area tree and the 
renderers. The inlineParent area has a property called "offset" (So 
have other areas).  This offset is used for baseline alignment, i.e. it 
is the offset relative to the dominant baseline. The question is: Is 
this offset relative to the content rectangle or the border rectangle?

In the example "some text <fo:inline border="..."> more text 
</fo:inline>" if the offset is for the content rectangle it would be 0 
if the offset is for the border rectangle it would be "- (Border + 
Padding) width". Currently the LM sets it to 0. Therefore the renderers 
would need to compensate for that when drawing the borders (which is 
currently not done). Alternatively the LM could take the border into 
account when calculating the offset and the renderers don't need to 
make any adjustments in the BPD direction. Anyone knows what the 
original design intention was?

Another question for the "Knuth" experts. It appears the inline LMs 
don't make provisions in the IPD for borders/padding on inlines. I 
assume border/padding is logically like a &nbsp; (with the width of the 
border + padding) in front of the first and after the last character of 
the inline assuming .conditionality=discard, that is we don't want to  
have let's say a left border alone on the end of a line with the text 
starting on the next. For .conditionality=retain this width needs to be 
reserved as well at the beginning and end of each intermediate line. 
Any suggestions how this can/should be integrated into the linebreaking 
algorithm?

Manuel

On Fri, 2 Sep 2005 03:29 pm, Manuel Mall wrote:
> 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