--- Comment #9 from Mehdi Houshmand <> 2011-04-18 03:42:47 EDT 
> I am far from convinced that this justifies the added computational complexity
> of walking up the tree, and checking all static-contents for a retrieve-marker
> that _might_ retrieve a particular marker.

I am of the same frame of mind, I think that's neither feasible nor really

> A lot depends on the actual structure of the subtree. FO is quite verbose, so
> even a small table already costs quite some chars, which does not always weigh
> up to simply instantiating the FONodes to store the data.
> If we're really serious about further optimization, then in terms of 
> footprint,
> the most optimal situation may just be to create a generic MarkerDescendant
> node type, and convert those into the proper FONode subclass later, if and 
> when
> they are actually retrieved.
> That is: as opposed to the current approach of immediately instantiating the
> proper type at parse time, and cloning those instances later, when the area
> tree is built.

I think implementing this would/could get fairly involved. I'm not sure an
intermediary object would be the proper approach. If we want the FOTree to be
an object manifestation of the FO, adding objects types that aren't a part of
the FO spec would break it's adherence with the spec.

I hadn't considered that the markers can have a hierarchy of children, or at
least I hadn't considered that this could be several levels deep rather than
just #PCDATA or a single-level block or two. That would make postponing
instantiating any children unnecessarily difficult. It would also mean that
we're parsing FO in the layout manager, which I don't think there's a precedent
for, nor is that the duty of the layout manager. I'm beginning to think the
initial approach, validating in AbstractRetrieveMarker as it binds objects to
itself may be the way to go. We may be forced to do an "instanceof FObjMixed",
to validate #PCDATA separately.

> Strictly speaking, in the current process, some space is still taken up by the
> unused references for members in flow.Block, flow.Table, FOText... That space
> is actually wasted, since the specified properties/attributes are stored in a
> Map that is associated with the Marker. 
> If we strip the MarkerDescendants to be lean, basic FObj instances, that might
> save some in larger documents with a lot of markers, especially if only a
> relatively small amount are actually retrieved.

That would mean adding an object that wasn't a part of the FO spec into the
FOTree. I'm not sure that's a good idea. It would be fairly confusing for
anyone looking at this at a later date, they'd see MarkerDescendants, refer to
the spec only to find it not there. No amount of commenting code would prevent

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to