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

Reply via email to