Thanks for looking through the code, Simon.

--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> 
> I have a remark on the logic of nextCharCalled. It
> is equal to
> curIndex - startIndex. Also, in remove() you should
> separately
> consider the case nextCharCalled == 0: it should not
> happen.
> 

"nextCharCalled" is a terribly named variable--but I
haven't thought of anything better.  Suggestions
welcome for its renaming.  

The process of moving from "RemoveA" (where I can just
nicely increment the startIndex, i.e., to remove
leading spaces) to "RemoveB" (where I need to start
doing arraycopies, e.g., to remove spaces between
words) is activated when two or more consecutive
nextChar() iterations occur *without* a remove() call
in between.  This would indicate that we've
encountered a valid character, so we've hit a word and
now any subsequent space removal has to occur via
RemoveB method.

Whenever remove() is called during RemoveA time, I
just keep resetting it to zero for the logic above to
occur.  It may not be the best, however, as I
mentioned earlier RemoveB appears to be called too
soon too often.

I'll get all this commented soon in the code.

> I have looked at the output in the area tree (at
> output). It does not
> reproduce the error in the first block of my test
> fo, the one with the
> colored inline FOs. That may be an error of the PDF
> renderer. 

I'm unsure if this is good news or bad news.  ;-)  But
anyway, more work for us...

Glen

Reply via email to