On Mar 13, 2006, at 19:53, [EMAIL PROTECTED] wrote:
Hi,
forget everything I said about that Length- and unit-retrieval from
fo.flows, I've found the mistake. I'll do it the other way 'round,
instead of calculating from the fixed to the proportional ones I'll
hand it over to the PercentBaseContext first (normalizing
proportional and percentage widths to values <1.0). If table width-
attribute is "auto", I'll assume 100% width. Though I need the
table's width if it's not proportional or auto, e.g. width="190mm".
I don't really see the problem in that.
I guess, if the RTF renderer --as was already suggested-- needs to
keep its fingers out of the layout package, then the correct way to
go about that --at least, IMO-- would be to have one class in the RTF
package implement the PercentBaseContext interface. An instance of
that class can then be used inside the RTFHandler, and passed back
into the properties subsystem, without having to import anything from
the layout package.
BTW, dunno if you noticed, but you can pass a null into i.e.
LenthRangeProperty.getOptimum() to get to the underlying Property,
without the need for a PercentBaseContext...
(~ something like: LengthRangeProperty.getOptimum(null).getNumeric
().getValue()?)
In additional this getObject-topic is still open...
Eclipse's call hierarchy shows these methods are definitely being
used...
AFAICT, at first glance this seems to be used to cast certain types
of Property instances to generic Objects before re-casting them to
fit the CompoundDatatype interface --the latter cast will definitely
not pass the compilation stage, since Property does not implement
CompoundDatatype (= not all properties are compound properties). What
if the programmer knows beforehand that this cast *will* succeed? The
only viable option seems to be to trick the compiler into believing
that it just might work... Convenient, no? :)
Cheers,
Andreas
