RTF and table/column widths

[b....@freenet.de]

Hi there,

after being silent for I while, I have some questions, only to be sure. First one is raised by the following table column attributes:

width=1.1; width=3pt; null; width=22%; width=19mm;

I implemented it like this:

1. determine smallest fixed width
2. if no smallest fixed width is given:
2.1 sum up all weights
2.2 divide table's total width by sum of weights
2.3 muliply each weight with this factor
3. else
3.1 multiply all weights with the smalles fixed width
3.2 sum up all percentages
3.3 determine width of 1% based on available fixed widths (1., 3.1)
3.4 multiply all percentages with 1%-width

So according to the numbers above the widths will be (mpt):
        #0=3300
        #1=3000
        #2=3000
        #3=17814
        #4=53858

Correct any of the decisions if I'm wrong. I made some dirty hack to get the right unit from anonymous Length-interface-realizations (instanceof-operator) and found PercentLength.value()-method in a twilight zone (cite: "really necessary?"), every other Length-realization is able to return the "naked" value (TableColLength.getTableUnits(), FixedLength.getValue()<- no context!). Is there another way calculating the widths more "polite" (I don't like instanceof-operations, casts and that sort of thing, Length should be able to return the unit and the value, in addition to a value filtered through the PercentBaseContext)?

I'm quite unsatisfied, due to the fact, that I did nothing RTF-specific until now. Did I re-invent the column-width-algorithm, is it hidden somewhere and already working fine? (I've attached the fo.flow.TableColumn to the rtf.TableContext and calculated the widths when the first row starts, maybe the Table should do this on it's own, being a column container, returning the widths if needed...which would lead to a stateful parser instead of re-programming the same state-objects and  -transitions for every rendering engine....). It's getting more and more like a basic LayoutManager (being nested, holding fo.flow-objects, doing some calculations...)

Thanks for any comment, maybe I'll finish this chapter this week, opening some sort of discussion about moving some basic functionalities to a more abstract level. Thanks for being patient...



"Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken"
www.klarmobil.de/index.html?pid=73025