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.
In fact, in alt.design, getPropertyValue(PropNames.LEADER_LENGTH_MINIMUM) etc.
Speaking of the minimal API, why not PropertyValue getPropertyValue(int propertyIndex)? This is presumably defined on FONode or some such, and FONode also presumably knows how to navigate the FO tree and related Area tree in order to resolve percentages and the like.
<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.
See above. In alt.design, all compounds are shorthands, and all shorthands are presumed to have been resolved into their components during FO Tree building.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>