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
