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? Depending on the file size it might take some time though? -----Original Message----- From: Andreas Delmelle [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2008 8:41 PM To: [email protected] 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 --------------------------------------------------------------------- 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]
