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? > 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). :-) 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. :-) Jeremias Maerki
