J.Pietschmann wrote:
Thanks for taking the time to explain your thoughts they are appreciated.
snip/
One point is that I didnt think Line BPs were kept past the call to
addArea methods, which is AT construction and well before rendering. The
TSAdjust properties is on the TextArea object which
Chris Bowditch wrote:
I lean somewhat to the first strategy, because memory is usually more
of a problem then bare performance.
This appears to be a contradiction, did you mean the last strategy?
Well, I meant the second (free memory as early as possible).
J.Pietschmann
J.Pietschmann wrote:
Thanks for your responses, they are useful in helping my thought process.
Well, the line may be parsed while rendering, which means you don't have
to create area objects, roughly:
StringTokenizer tok=new StringTokenizer(...);
while( tok.hasMoreTokens ) {
String word
Simon Pepping wrote:
The trouble is renderText is being presented with a whole line at a
time. It should be presented with smaller chunks if it is going to be
able to add the TSAdjust space to each word space.
Do you need to break the line is as many separate text areas as there
are word
Chris Bowditch wrote:
An interesting idea... but hasnt this already been done in more detail
in TextLM.getNextBreakPoss? So why should the renderer have to do it
again (although in less complexity)? I would rather have layout do this,
otherwise this logic would have to live in every renderer.
Simon Pepping wrote:
Do you need to break the line is as many separate text areas as there
are word spaces ( + 1 )?
Well, the line may be parsed while rendering, which means you don't have
to create area objects, roughly:
StringTokenizer tok=new StringTokenizer(...);
while( tok.hasMoreTokens )
Simon Pepping wrote:
Thanks for taking the time to reply. It is very useful to discuss this
with someone who has an idea of how layout works.
This loop only counts word spaces.
Yes, I know, but I believe it should do more than that.
Later the member iTSadjust is set
on the text area:
Chris Bowditch wrote:
The renderer should add this to the X offset for every piece of text it
places in the renderText method. It is missing ATM, but it is easy
enough to add.
Unfortunately, ther is more to justification than just expanding spaces.
In the long term, you'll have to deal with
Chris,
On Fri, Jan 09, 2004 at 05:20:42PM +, 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
