Looks like PreserveWhiteSpace flag in the XmlDocument object seems to be
doing the trick so far. (in c#)

-----Original Message-----
From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 3 June 2008 11:30 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Editing Text in the Intermediate Format

On 03.06.2008 15:22:04 Martin Edge wrote:
> Hm... I'm editing the Intermediate file directly.. but It's possible I
> suppose it applies to that as well..
> 
> Will give stripping it entirely of spaces.. if that's the solution,
> shouldn't we add logic to clean it of spaces before attempting a PCL
> conversion? 

As Andreas noted, it might be a good idea to fix the
whitespace-collection behaviour. Remains the question of who's doing it.
This wasn't a problem, yet, because we don't have any automated test
cases that actually change anything in the XML. The XML is just piped
into the AreaTreeParser again in the tests to see if the parser can read
everything in that the XMLRenderer wrote out and that no information is
lost.

> Depending on the file size it might take some time though?

Better not generate the unnecessary whitespace in the first place.
You should really find out if you can disable pretty-printing when
serializing the modified XML.

> 
> 
> -----Original Message-----
> From: Andreas Delmelle [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, 3 June 2008 8:41 PM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: Editing Text in the Intermediate Format
> 
> On Jun 3, 2008, at 10:57, Martin Edge wrote:
> 
> > I don't half wonder whether the Intermediate parser is a little  
> > dodgey?
> >
> > I'm pretty sure I'm not doing anything silly,  but I get the  
> > intermediate file I generate, process that to PCL, I can see it fine.
> >
> > I simply open the .AT file, paste into Visual Studio which formats  
> > it, and paste it back, and the PCL no longer generates properly.
> > Perhaps white spaces are a problem?
> 
> Yep. If spaces are encountered in the input FO, then this will result  
> in <space> nodes in the area tree. Linefeeds would lead to the  
> generation of a new <lineArea>. The <word> nodes are expected to not  
> contain any space or linefeed characters themselves.
> The org.apache.fop.area.AreaTreeParser does not compensate for  
> spaces, linefeeds and/or carriage-returns being added due to  
> intermediate reformatting. This is generally not a problem, unless  
> the area tree is serialized to a file and treated in an editor (which  
> is not really good practice). Reformatting should really only be used  
> to make the XML human-readable for debugging. Once the XML needs to  
> be fed back into any consuming application, be sure to undo the  
> pretty-printing if you expect identical results. In this case, the  
> white-space should obviously be ignored, but from a more abstract  
> point-of-view, there are no criteria for the consuming application to  
> decide whether the additional white-space is significant or not.
> 
> That said, AFAICT there is indeed something buggy in the handling of  
> the SAX characters() event in AreaTreeParser. The characters are  
> appended to a StringBuffer, but this StringBuffer is only reset in  
> endElement() events.
> 
> IIC, this means that the AreaTreeParser.content StringBuffer for the  
> first <word> node will get to contain all the accumulated leading  
> white-space characters of its ancestor nodes.
> 
> > How do you "debug" in Java? :)
> 
> Same as most other programming languages: using an IDE with  
> integrated debugging facilities. ;-)
> 
> For help on setting up FOP in an IDE, see http://wiki.apache.org/ 
> xmlgraphics-fop/FOPIDESetupGuide. Note that some of the info is  
> outdated, so the steps may vary slightly for more recent versions of  
> the IDEs. Updates to the Wiki are always welcome.
> 
> 
> HTH!
> 
> Cheers
> 
> Andreas




Jeremias Maerki


---------------------------------------------------------------------
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]

Reply via email to