On further exploration, because there are element in a non-SVG namespace between the whitespace text nodes, they shouldn't/couldn't be normalized. Thus, the issue is that in the case of multiple child text nodes, "stripfirst" will only apply to the first text node. At first glance, this would appear to be a bug. Perhaps the "first" variable should be reset to true upon encountering a non-text node or a node not in the SVG namespace.
We'll experiment a bit and see what happens in this case. -----Original Message----- From: Rick Bullotta [mailto:[EMAIL PROTECTED] Sent: Monday, December 27, 2004 9:50 AM To: batik-dev@xml.apache.org Subject: RE: Whitespace Handling in Batik vs ASV Looking at the source in SVGTextElementBridge.java, it would appear that additional leading whitespace would not be properly stripped when there are multiple child text nodes containing only whitespace (I believe this may be due to the "first" boolean variable being outside the loop iterating the child nodes and therefore incorrectly not setting "stripFirst" for text nodes other than the first). Assuming for a moment that somewhere in the SAXSVGDocumentFactory implementation, DOM normalization is not occurring, two questions come to mind, I tried adding an explicit call to doc.normalize(), to no avail. Iterating for empty text nodes (and removing them), as Tonny has suggested, would be a workaround, but a definite performance hit. Open to any other suggestions... Rick Bullotta CTO Lighthammer Software (http://www.lighthammer.com) -----Original Message----- From: Thomas DeWeese [mailto:[EMAIL PROTECTED] Sent: Sunday, December 26, 2004 1:44 PM To: batik-dev@xml.apache.org Subject: Re: Whitespace Handling in Batik vs ASV Rick Bullotta wrote: > A bit more information: > > It appears to be that the various viewers handle the > "xml:space=preserve" attribute.ASV and SharpVectorGraphics seem to > ignore it altogether, and Batik seems to honor it (somewhat), but still > converts linefeeds into spaces when preserve is not enabled. No it drops linefeeds when xml:space is set to "default" the question is how child elements of the text element interact with white space handling. So in your second case you have: [space 1]<element/>[space 2][text][space 3] So clearly "space 1" and "space 3" are to be eliminated the question is what should happen to "space 2"? Is it part of leading space? or is it part of 'text'. What if element is a tspan/tref (even if empty?), what if it's a glyphRef (which is always empty). What if it has a separate value for "xml:space"? This is really quite complex. I don't actually think the specification is sufficiently clear on the handling of child elements to properly implement this. One thing that really has me wondering is that is seems to strongly imply that xml:space is only used on the root 'text' element. If this is the case then you could take a model where all child 'text' is put in the string that is passed to the collapsing function. This would still leave a question of when a string of whitespace is collapsed that has content from multiple elements how does one style the resultant whitespace? As well as how to treat glyphRef which doesn't have any real text content associated. BTW in the future it is best to post working examples. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
