Re: fo:marker and white space
Jeremias Maerki wrote: Sounds like a good plan to me. Would you go after that? Jeremias: I have similar concerns to Manuel about this. Moving the handleWhitespace method to a different class is probably okay, but I don't think we should start making any major changes to Whitespace handling until we have the design nailed down. It is still unclear exactly what the spec intends in some places. Manuel has written a Wiki which attempts to document the intention of the spec and presents some ideas on how to implement this functionality. http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling On 15.11.2005 18:06:13 Andreas L Delmelle wrote: In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Chris
Re: fo:marker and white space
Well, my fault. I didn't so much follow the whole whitespace discussion to know every detail. I assumed there was some kind of consensus by now. On 16.11.2005 11:15:48 Chris Bowditch wrote: Jeremias Maerki wrote: Sounds like a good plan to me. Would you go after that? Jeremias: I have similar concerns to Manuel about this. Moving the handleWhitespace method to a different class is probably okay, but I don't think we should start making any major changes to Whitespace handling until we have the design nailed down. It is still unclear exactly what the spec intends in some places. Manuel has written a Wiki which attempts to document the intention of the spec and presents some ideas on how to implement this functionality. http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling On 15.11.2005 18:06:13 Andreas L Delmelle wrote: In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Chris Jeremias Maerki
Re: fo:marker and white space
On Wed, Nov 16, 2005 at 08:15:47AM +0800, Manuel Mall wrote: I have no problems with the suggestion to move the white space handling from Block into its own class so other fo's that need it can make use of it. However, I still need to be convinced that pushing it down to inline level is actually of benefit. I am afraid we will end up with the same problem we now have at LM level, that is text for a paragraph needs to be analysed across fo boundaries and the current LM structures are very much in the way of doing that. Whitespace needs to be handled across fo boundaries as well. The current iterator structure was designed to exactly facilitate that. It seems to be doing it well and I see no reason to replace it. linefeed-treatment is a local operation on a single character. white-space-collapse does not cross FO boundaries because the spec limits this to sibling character FOs. Only white-space-treatment extends beyond FO boundaries, but its treatment in handleWhitespace is only the first stage. At line building it needs to be revisited. That means that theoretically handleWhitespace can be done within each FO. But practically it may be better to wait until we have settled ideas about this stage, scanning for linebreak opportunities and gathering of Knuth elements. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: fo:marker and white space
Debugging shows: The FOText instances under fo:marker (just before and after the fo:block) don't get processed for whitespace treatment. Block.handleWhitespace isn't accessible to it. That's why the whitespace isn't removed and causes additional lines. The fix is probably to extract handleWhitespace from Block into a separate class and call it from Block and Marker. So, this is a bug, to be fixed after the release I guess. On 15.11.2005 05:56:19 Manuel Mall wrote: I was looking at clipping warnings generated by examples/fo/markers/hide.fo when I noticed that white space around fo:marker seems significant with respect to the output generated when the marker is retrieved, e.g.: fo:marker fo:block some text /fo:block /fo:marker when retrieved produces: empty line some text empty line while: fo:markerfo:blocksome text/fo:block/fo:marker just generates: some text I am suspicious that this is wrong and both inputs should produce the same output. For a test case and its output see: http://people.apache.org/~manuel/fop/marker_test.xml http://people.apache.org/~manuel/fop/marker_test.pdf Manuel Jeremias Maerki
Re: fo:marker and white space
On Nov 15, 2005, at 10:03, Jeremias Maerki wrote: snip / The fix is probably to extract handleWhitespace from Block into a separate class and call it from Block and Marker. In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Extracting handleWhitespace() into a separate class would, in any case, be A Good Thing. My 2 cents. Cheers, Andreas
Re: fo:marker and white space
Sounds like a good plan to me. Would you go after that? On 15.11.2005 18:06:13 Andreas L Delmelle wrote: On Nov 15, 2005, at 10:03, Jeremias Maerki wrote: snip / The fix is probably to extract handleWhitespace from Block into a separate class and call it from Block and Marker. In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Extracting handleWhitespace() into a separate class would, in any case, be A Good Thing. My 2 cents. Cheers, Andreas Jeremias Maerki
Re: fo:marker and white space
On Wed, 16 Nov 2005 03:45 am, Jeremias Maerki wrote: Sounds like a good plan to me. Would you go after that? I have no problems with the suggestion to move the white space handling from Block into its own class so other fo's that need it can make use of it. However, I still need to be convinced that pushing it down to inline level is actually of benefit. I am afraid we will end up with the same problem we now have at LM level, that is text for a paragraph needs to be analysed across fo boundaries and the current LM structures are very much in the way of doing that. Whitespace needs to be handled across fo boundaries as well. The current iterator structure was designed to exactly facilitate that. It seems to be doing it well and I see no reason to replace it. Manuel On 15.11.2005 18:06:13 Andreas L Delmelle wrote: On Nov 15, 2005, at 10:03, Jeremias Maerki wrote: snip / The fix is probably to extract handleWhitespace from Block into a separate class and call it from Block and Marker. In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Extracting handleWhitespace() into a separate class would, in any case, be A Good Thing. My 2 cents. Cheers, Andreas Jeremias Maerki
fo:marker and white space
I was looking at clipping warnings generated by examples/fo/markers/hide.fo when I noticed that white space around fo:marker seems significant with respect to the output generated when the marker is retrieved, e.g.: fo:marker fo:block some text /fo:block /fo:marker when retrieved produces: empty line some text empty line while: fo:markerfo:blocksome text/fo:block/fo:marker just generates: some text I am suspicious that this is wrong and both inputs should produce the same output. For a test case and its output see: http://people.apache.org/~manuel/fop/marker_test.xml http://people.apache.org/~manuel/fop/marker_test.pdf Manuel
