xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From b.ohns...@freenet.de
Subject RTF and table/column widths
Date Sun, 12 Mar 2006 23:01:25 GMT
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


Mime
View raw message