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]
