Peter B. West wrote:

> > It would be really nice to have a getLeaderLength()
> > which returns a MinOptMax. this means the getLeaderLength()
> > has:
> >  - resolve percentages and functions
> >  - deal with the leader-length shorthand setting before this
> >  - deal with inheritance (n/a here, fortunately)
> Or getLeaderLengthMin(), getLeaderLengthOpt(), getLeaderLengthMax(),
> with all values resolved.

Yes, yes, yes. Since we are trying to eliminate the need for unnecessary
object creation, why create a MinOptMax object? Why not just return the
three resolved values in separate methods. Anything that uses the
information will have to separately address the 3 pieces of data anyway, so
I don't see any advantage to packaging them in an object.

<Joerg speaking here/>
> > One of the complications in the maintenance code is that
> > the code in the FO layout routines had to deal with resolving
> > percentages. OTOH, the generator is mainly so ugly because
> > Keiron et al. tried hard to press the shorthand handling
> > into a common scheme. There should be better solutions for
> > either problem.

Nobody but the FO Tree should ever have to think about compound or shorthand
properties. AFAICT, all examples of these can be decomposed into their
components. The FO Tree's API should deliver only the decomposed (i.e.
lowest-common-denominator or LCD) values. And yes, definitely, percentages
should be handled on the FO Tree side. Make FO Tree do all of that work.

Victor Mote

Reply via email to