On Fri, 2 Sep 2005 10:01 pm, Jeremias Maerki wrote:
> On 02.09.2005 15:38:41 Manuel Mall wrote:
> > The problems reported here with e-g and padding / borders apply
> > equally to i-f-o. It's not too hard to fix. While doing this I
> > noticed that the code for the i-f-o LM and e-g LM is logically
> > largely identical although some bits have been coded slightly
> > differently.
> >
> > Any concerns if I put a common LM for i-f-o, e-g that  into the LM
> > inheritance hierarchy (working name ForeignContent LM, i.e. content
> > not native of XSL-FO)?
> >
> > So we have something like:
> >    i-f-o LM implements ForeignContent LM
> >    e-g LM implements ForeignContent LM
> > and
> >    ForeignContent LM implements LeafNode LM.
>
> You mean "extends", not "implements", right?
>
Yes, of course...

> > This would allow all the code related to the viewport generation,
> > content scaling, and rectangle sizing for i-f-o and e-g to be in
> > one place only.
> >
> > The i-f-o and e-g LMs would become very small basically only
> > providing the image or foreignObject area to be placed into the
> > viewport.
>
> +1 to that but since this new class will be abstract I'd like to have
> it marked as such by naming it AbstractGraphicsLM (which also shows
> how I would name it). :-)
>
Yes, should be Abstract and Graphics is fine with me. Just wasn't sure 
if all possible i-f-o's will be of a graphic nature. But that doesn't 
really matter.

> Thanks for handling that.
>
> BTW, I'll commit a tiny little change in IFOLM in a few minutes, due
> to a change in to FO tree. Shouldn't be a problem, though. Well, I
> hope. :-)
>
Noted :-)

> Jeremias Maerki

Manuel

Reply via email to