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.


Reply via email to