DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27901>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27901 TextCharIterator.remove() does not work properly ------- Additional Comments From [EMAIL PROTECTED] 2004-03-24 22:49 ------- Hi Luca, Thanks, you're completely correct. I've spent a lot of time trying to get this right, but obviously I'm not done yet. Just FYI, for a long time, we had a problem of a leading space remaining at the beginning of the first FO-Text instance of the fo:block (During processing, the fo:block is chopped up into FOText instances.) The first thing to remember about the FOText instance is not all of the string needs to be processed--we have leading spaces to remove for each instance: { leading space } the text is here Old process (which had the leading space bug), did this: 1.) remove a space 2.) arraycopy everything over one to the left (see [1] at the bottom) 3.) repeat 1&2 until leading space gone (lots of arraycopy's's) What we were left with is as follows for the TextLayoutManager to use: Valid text<--- invalid trailing chars ---> ^ ^ ^ a b c a - 1st position of string to process (always at position 0) by Text LM b - "length" param to stop processing for Text LM c - (irrelevant) end of FOText char array (always remains the same after allocation). So the TextLayoutManager would render from position 0 to a "length" value which would point to the last valid value. My new algorithm was also an attempt to get rid of all the arraycopy's. So instead of removing characters and shifting everything to the left, I just wanted to increment a start pointer. So what TextLayoutManager renders is from (start character, natural end of char buffer of the FOText object.) { leading space } the text is here ^ ^ a b a - start value b - natural end of char array (i.e., array.length) But my simple solution failed to take into account the need to remove spaces *within* the fragment, not just the leading spaces. So, as you mention, "the text is here" would be rendered as "e text is here." I may need to bring back the old code, but I'd also like a hybrid approach. Extra spaces between words are relatively rare compared to initial leading spaces (at least, that what my testing showed.) I'd like to continue incrementing the start value until the first word occurs, *then* start with the arraycopy's for the extra spaces between words. This would mean: { leading space } the text is here ^ ^ ^ a b c a - start value b - end value (couple of decrements from (c) below due to extra spaces between words c - natural end of char array (i.e., array.length) That would involve re-creating the "length" (or "end") value in FOText, and using it within TextLayoutManager. I'll look into this soon (but patches of course are welcome in case you're faster than me! ;) Thanks again (Grazie!), Glen [1] (line 159) http://cvs.apache.org/viewcvs.cgi/xml- fop/src/java/org/apache/fop/fo/FOText.java?r1=1.16&r2=1.17&diff_format=h
