Re: Re: RTF and table/column widths - table width attribute

[b....@freenet.de]

Hi again,

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".

In additional this getObject-topic is still open...



1 Million Singles in Ihrer Nahe. Finden Sie Ihren Traumpartner
bei Deutschlands beliebtester Partnerboerse:
http://singles.freenet.de/index.html?pid=11512

Re: RTF and table/column widths - table width attribute

[Andreas L Delmelle <a_...@pandora.be>]

On Mar 13, 2006, at 19:53, b.ohnsorg@freenet.de 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