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
