Re: Whitespace Handling in Batik vs ASV

2004-12-26 Thread Thomas DeWeese
Rick Bullotta wrote:
A bit more information:
It appears to be that the various viewers handle the 
xml:space=preserve attributeASV 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]


Re: Whitespace Handling in Batik vs ASV

2004-12-26 Thread Tonny Kohar
Hi,

 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.

We have similar problem, and our current workaround (not solution) is
once the DOM tree is build, iterate the DOM to find empty Text node and
remove it.

The larger the Document, the longer the time to iterate the DOM tree.

Regards
Tonny Kohar
-- 
Sketsa 
SVG Graphics Editor
http://www.kiyut.com



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]