J.Pietschmann wrote:
>  > Keiron Liddle wrote:
>  > Does that mean we should not attempt to solve this problem?
>  > Or that we should attempt to solve the problem twice independantly.
> Actually, this problem has been tackled several times already, in
> particular if we include Peter's efford, with no really satisfying
> solution yet. In part, this is due to some attempts to keep it as
> generic as possible, and to some sigificant degree also due to the
> hairrising complexity of the matter itself.

While keeping in mind the gotchas that are always lurking in this spec, 
I am confident that I am almost at the point wher I can say that I have 
developed a really *personally* satisfying solution for properties.  By 
satisfying I mean
1) that it is complete; not that I have implemented every function and 
expanded every shorthand, but that the framework I have in place will 
handle anything that those unimplemented elements will throw at it.
2) that it is robust; by which I do not mean that it conforms to best OO 
practice, but that it works predictably, reliably and (see above) 

And yes, it is absolutley choc-a-bloc with instancesof and casts, which, 
I have recently been led to understand, are expensive operations.  What 
a pity.  It is a good reason for wanting to minimise them though.  I 
note that the received wisdom about efficiency in Java took a pounding 
from Joerg's findings about the negligible performance impact of 
replacing synchronized Collections with unsynchronized.  That was 
extremely encouraging news, and is presumably down to improvements in 
the JVM.

> I myself take issue with:
> - Property handling is hard to understand, with a gadzillion of
>   indirections and odd "instanceof" and casts and of course, the
>   XSL generated code.
> - There are a lot of classes involved, sometimes with seemingly
>   duplicated semantics.
> - The DirectPropertyList abomination.
> - In HEAD, there appears to be another batch of Trait classes which
>   also appears to deal with data which the various Property are
>   apparently used for.
> At first, there should be a clear distinction drawn between XML
> attributes and FO properties.
> So what's wrong with the following approach:
> - Pass the sax.AttributeList to the FO's constructor.
> - Have a FONode method which goes through the attribute list and
>   +  gets a PropertyMaker from a hash table the same way a FObj.Maker
>      is retrieved and store it in a list, except for "font-size" and
>      "font" which are processed immediately
>   +  walk the list and invoke a "parse" method with the XML attribute
>      value, the FO and the parent
> - The parser gets the parse context from the FO and parses the
>   attribute value in a more or less customised way.

More less than more, I should think.  Parsing is inherently "generic". 
E.g., I assume that you would use the same tokenizer and first-level 
parser.  There is a refinement/verification stage which is property 
specific, in which expression results are checked for type and range. 
But even at this point, there is, except in isolated instances, a range 
of possibilities.

> - Once a property is parsed, resolve the value as far as possible and
>   tell the FO to store it. Keep a bit whether it was already set for
>   conflicts with shorthands which may be evaluated later and for the
>   "get-nearest-specified value". The latter information can be
>   discarded in the FO's end() method (which is underutilised anyway).
> There should be no need to actually store for many properties most
> of the data types which can be specified in an XML attribute, for
> example font-size can always be resolved to an absolute value. Bad
> things are for example alignment-adjust which must still store an
> alternative of an enum, an absolute length and a percentage.
> There are, naturally, concerns that if every property is stored in the
> FO, it becomes large. An idea to solve this is to create bundles of
> properties which are likely to change together, as already partially
> done in FontState and other objects, check after property resolution
> whether a bundle with the same values has already been used elsewhere
> and reuse this. Some of these bundles, in particular FontState and border
> settings can be passed through the areas to the renderer, which might
> even improve or simplify reuse of objects there.
> I think I posted already that for the "franklin_2pageseqs" example
> more than hundred FontState objects are created, while there are only
> three different combinations of values.
> The problematic point is to choose the bundles wisely: if they hold
> too many or too unrelated properties, there wont be much reuse; if they
> are too small, there is no gain because the references to the property
> bundles still take memory. I had to abort a few attempts at designing
> them because my brain seems to be too small to handle this :-(

Which says something about the feasibility of this approach.  If someone 
of your talent can't make it work, it doesn't look good.  You might try 
applying a little more of the magic ingredient - time - before 
abandoning it, but, prima facie, it applies only in very specific 
circumstances, like FontState.

> I tried to implement this for text decorations (TextState), actually
> there can be at most 8 different value combinations (disregarding
> "blink"), so I preconstructed these and had the PropManager select and
> return the appropriate TextState object. Interestingly, this seemed
> to *increase* memory consumption of the test run, despite, of course,
> much less TextState objects are constructed. I'm still stumped.

It might be useful to look at .../fop/datatypes/TextDecoration.java and 
TextDecorator.java in the FOP_0-20-0_Alt-Design branch for another approach.

Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to