Chris,
On Fri, Jan 09, 2004 at 05:20:42PM +0000, Chris Bowditch wrote:
> Chris Bowditch wrote:
>
> The problem isnt that TextLM.getNextBreakPoss isnt finding BPs, problem
> is with addAreas, which, just skips over all the BPs and creates a
> single TextArea. This is evident from the following at the start of
> TextLM.addAreas:
>
> /* On first area created, add any leading space.
> * Calculate word-space stretch value.
> */
> while (posIter.hasNext()) {
> LeafPosition tbpNext = (LeafPosition) posIter.next();
> ai = (AreaInfo) vecAreaInfo.get(tbpNext.getLeafPos());
> if (iStart == -1) {
> iStart = ai.iStartIndex;
> }
> iWScount += ai.iWScount;
> }
This loop only counts word spaces. Later the member iTSadjust is set
on the text area: t.setTSadjust(iAdjust / iWScount). It seems that
this is supposed to take care of space stretching, I do not know
how. I guess the renderer should know how to use this information. In
my test runs, it is equal to 0, which explains the lack of
justification. I am not sure whether it is necessary to break up the
text area into pieces.
The real calculations are happening much earlier, in the
getNextBreakPoss loop. In LineLayoutManager.makeLineBreak, ipdAdjust
and dAdjust are calculated based on the length of the line, and set as
members on the new linebreak position. In the ensuing addAreas loop,
LineLayoutManager.addAreas fetches these again from the linebreak
position and sets them on the layout context. From there they are
fetched by the above calculation and used in calculating iTSadjust --
with little succes at the moment.
ipdAdjust seems to be for scaling between min, opt and max. dAdjust
seems to be the scaling for justification.
These are my thoughts on the process.
Regards, Simon
--
Simon Pepping
email: [EMAIL PROTECTED]
home page: http://www.leverkruid.nl
public key: http://www.leverkruid.nl/personal/sp.asc
fingerprint: E3BF 7295 9AA8 8B8A C01A 219D FAAC 088C 6B28 F549
