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 taking the time to explain your thoughts they are appreciated.
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 is pa
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.
T
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 space
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:
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 )
Chris,
On Mon, Jan 12, 2004 at 10:22:00AM +, Chris Bowditch wrote:
> Simon Pepping wrote:
>
> >I am not sure whether it is necessary to break up the
> >text area into pieces.
>
> The trouble is renderText is being presented with a whole line at a
> time. It should be presented with smaller
J.Pietschmann wrote:
Unfortunately, ther is more to justification than just expanding spaces.
In the long term, you'll have to deal with leader expansion as well as
start and end space for inlines and perhaps letter spacing.
Leaders are particularly nasty because of they mey be aligned. It may
be
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 leade
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: t.setTSad
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 a
Chris Bowditch wrote:
The child LM of Line LM is Text LM. It appears that when dealing with
just plain text paragraphs, i.e. no fo:inlines or fo:wrapper changing
fonts within a line, etc, then there is almost a 1:1 relationship
between Line LM and Text LM. So when renderText is called on the
Fellow FOP Devs,
I've been thnking about how to implement Justified text in HEAD, and
would appreciate some suggestions/comments on my thought process.
I know Joerg posted something on this back in November in which he said
the missing piece was the renderer not resizing the spaces, but the
pr
13 matches
Mail list logo
