Jörg, Summarizing, you mean that
1. the layout system should calculate the justification and add corresponding word and space areas to the area tree; 2. the area hierarchy should be revised to make it as light-weight as possible, to minimize resource consumption. This is an interesting idea, that can be worked out. Recently, I heard that PDF would be able to do line justification by itself if the target line length is given; it pads the spacing in the line to achieve the target length. I do not know much about it; I do not even know which PDF component would have this capability. If there is any truth in it, it would mean that FOP could leave justification to the renderer. But probably that would only be valid for PDF output. Regards, Simon On Sat, Apr 17, 2004 at 10:16:54PM +0200, J.Pietschmann wrote: > Chris Bowditch wrote: > >Just want to add that I realise changing TextLM.addAreas isnt the only > >other change required to get jusitification working. The Renderers will > >need changing too, but I'm against the renderers computing their own > >splits, just give them each word as its own area if justification is on. > > This caused some problems in the maintenance branch code, although > the mistakes made there can be avoided. > The biggest problem is that lots of WordArea objects are created > which hang around some time and which also inherit a *lot* of > unnecessary (for them) fields from Area. I think some refactoring > of the Area hierarchy could be in order. The current state in the > maintenance branch is roughly like this: > Box (not many attributes) > + Space > | + DisplaySpace > | + InlineSpace (well, shoud be here, but actuall isn't) > + Area (position, border, padding, children, heigth, width etc.) > + BlockArea (content heigth&width etc.) > | + LineArea > | + etc. > | > + InlineArea > + WordArea (ugh, maybe this was TextArea instead) > | + etc. > + some non-word inline areas > Many inline areas can't have border, padding, background and > perhaps some other traits, and all the space is wasted in objects > which are instantiated *very often*. This added up to significant > ressource problems. > I'm still not quite sure what's the best approach to fix this. > In C++, it certainly would be multiple inheritance. In Java, > we could try using interfaces and some delegation: > interface Area > interface BlockArea extends Area > interface InlineArea extends Area > interface BorderPaddingBackgroundArea extends Area > interface NonBorderPaddingBackgroundArea extends Area > interface Space extends Area > class AbstractArea implements Area > class AbstractBlockArea implements BlockArea extends AbstractArea > class AbstractInlineArea implements InlineArea extends AbstractArea > class LineArea implements NonBorderPaddingBackgroundArea > extends AbstractBlockArea > class WordArea implements NonBorderPaddingBackgroundArea > extends AbstractInlineArea > class PageNumberReferenceArea extends WordArea > ... and so on ... > (Well, because AbstractBlockArea is supposedly abstract, what class > represents ordinary block areas? We need a good name here :-) Note > that the real block area class may have traits which are not > applicable to for example the line area class or the table row area > class.) > The code for accessing the border, padding and background traits will > be duplicated in all classes implementing the BPBA interface, but given > that the traits are combined in a single class, this shouln't be much > of a problem, should it? > Some inline areas may not have children, this could lead another set > of interfaces. > > A potentially second problem are the space non-areas. In the maintenance > branch code, display (block) space and inline space just have a height > (bpd) or a width (ipd), respectively. I'm not sure whether this is > sufficient, but perhaps it is. > > Regards > J.Pietschmann -- Simon Pepping home page: http://www.leverkruid.nl
