On 04.09.2005 16:34:35 Manuel Mall wrote: > 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?
I don't know. I assume it's relative to the content rect. The area package operates mainly on the content rectangle. See Area where the getAllocBPD() and getAllocIPD() calculate their values from other values. That means that LM operate mainly on content rectangles. The other way around would mean a complication anyway. > 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). ....for inline, right? That may have to do with the different allocation rectangles. Anyway, I think the approach is correct. It might simply be that there are differences in the handling of inline parent and block areas. > 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? Your alternative would start to mix approaches to much IMO. ATM, a lot of calculations are done in the renderers and that should stay that way. The only alternative I see is doing the absolute placements on a page entirely in the LMs and let the renderers only perform some painting instructions. We've discussed that earlier this year and did not pursue. Just look at AbstractPathOrientedRenderer.handleBlockTraits() which does all the necessary calculations to determine the right positions and offset. The same should be done for all other area elements. > 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 (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? Exactly like spaces, borders and padding in b-p-d for block-level objects: additional auxiliary boxes and penalties. See BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is the same as page breaking, only in a different direction. <snip/> Jeremias Maerki