Re: inline-container support
Keiron Liddle wrote: Hi Jens, Do you want to get started on implementing it in the redesign? What we will need is an InlineContainerLayoutManager that returns a single inline object as with other layout managers such as image. The inline-container area will have width, height and alignment. The renderers will need to handle the inline container, this might already be done but it wouldn't be tested. Inside the inline container it will need to find all the breaks and then to calculate the height. The IPD must be fixed and this will be passed down to the child layout managers. Once it has all the breaks all it need to do is set the height. When the areas are added it will get all the child LM's to add there areas from the breaks, then it will add the inline container to the parent and do the alignment. Keiron, Could you spell this out in a bit more detail if possible? I am also interested in how the inline-area copes with having to pass line-areas back up to a parent. I am thinking of the interpretation we developed on the basis of the clarification of the behaviour of various inline FOs. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: inline-container support
Hi Peter, For the inline-container all it does is return one or more inline viewport areas. I think, but need to check, that it only can create more than one viewport if the IPD of the contents is perpendicular to the parent IPD. This ensures that the areas a properly ordered. If the IPD is the same as the parent then there cannot be inline areas after the inline-container viewport unless the inline-container is finished in which case only one viewport will be created. The viewport/reference areas are almost the same as for images and instream foreign objects. Inside the reference area will be the block areas from the child block FO's stacked in the BPD. The IPD is either set or has a maximum of the parent IPD. So to find the dimensions of the inline container it needs to layout the child block areas and get the result. I'm not sure what you mean by pass line-areas back up to a parent as the child areas of the inline container are not passed up. This is a different situation than when there are blocks inside and fo:inline. Could you spell this out in a bit more detail if possible? I am also interested in how the inline-area copes with having to pass line-areas back up to a parent. I am thinking of the interpretation we developed on the basis of the clarification of the behaviour of various inline FOs. -- Peter B. West [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: inline-container support
Keiron Liddle wrote: Hi Peter, I'm not sure what you mean by pass line-areas back up to a parent as the child areas of the inline container are not passed up. This is a different situation than when there are blocks inside and fo:inline. Keiron, You're right, I was thinking of fo:inline, fo:bidi-override, etc. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
inline-container support
Hi! I've got a fo-task for which I need a working fo:inline-container-object. This feature seems not to be implemented in the 0.20.x-version. I would like to know weather support for this element is planned for the coming versions (maintenance or redesigned-branch). Are any milestones planned? Would it be possible / difficult to take part in the implementation-process myself if no support is planned? Best regards, Jens Wissmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: inline-container support
Jens Wissmann wrote: I would like to know weather support for this element is planned for the coming versions (maintenance or redesigned-branch). Are any milestones planned? No, yes, and no. Would it be possible / difficult to take part in the implementation-process myself if no support is planned? If youcan supply an explicit width, either absolute or as percentage of the width of the parent block, it's not all that hard: create a block area and add lines until you run out of either content or bpd. Then the more tricky aspects kick in: what to do if the bpd ends first, and how to vertical-align the whole beast. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: inline-container support
Hi Jens, Hi! I've got a fo-task for which I need a working fo:inline-container-object. This feature seems not to be implemented in the 0.20.x-version. I would like to know weather support for this element is planned for the coming versions (maintenance or redesigned-branch). Are any milestones planned? In the redesign it is not planned as such but we do want to implement it. Would it be possible / difficult to take part in the implementation-process myself if no support is planned? Do you want to get started on implementing it in the redesign? What we will need is an InlineContainerLayoutManager that returns a single inline object as with other layout managers such as image. The inline-container area will have width, height and alignment. The renderers will need to handle the inline container, this might already be done but it wouldn't be tested. Inside the inline container it will need to find all the breaks and then to calculate the height. The IPD must be fixed and this will be passed down to the child layout managers. Once it has all the breaks all it need to do is set the height. When the areas are added it will get all the child LM's to add there areas from the breaks, then it will add the inline container to the parent and do the alignment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
