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
