Hi Art,

Thanks for your response to my posting.  I think a "mode" attribute to
indicate whether to preserve text or format is a good idea.  Formatting
issues can often be cleaned up by post-processing on the generated file.
I'm already doing this to remove the extra new line feeds that I've had to
add to solve the line overwriting problem.  But when 2 lines are rendered
onto each other - there is no way to fix that in a post-processing step.

Do you or anyone else reading this thread have an idea how hard it would be
to modify the TXTRenderer to preserve output text so that overwriting never
occurs?  Even though FOP's text output was never meant to be production
quality, it's pretty darn good.  I think a little tweaking to make it better
would be a nice feature to have.  I can volunteer to work on this.  A little
guidance would help me a lot.  Who is most familiar with the TXTRenderer?
Thanks, -V

Vincent Illiano
Senior Programmer/Analyst
Duke University Heart Center

> ----------
> Sent:         Monday, June 16, 2003 2:37 PM
> Subject:      RE: Ascii file generation questions
> I do not know about the future of the TXTRenderer. But I do know a little
> bit about it's past.
> The overwrite problem occurs because the TXTRenderer attempts to match the
> positioning/layout of the PDF/PCL Renderers. Unfortunately plain text of
> course does not have precise line positioning. Essentially the TXTRenderer
> attempts to fit the layout onto a fixed character matrix. Quantization
> effects cause the overwrite when a subsequent line ends up at the same
> line
> in the matrix as a previous line. I do not know that there is a perfect
> solution to this problem. Perhaps extra lines could be added if an
> overwrite
> would occur, but then the layout would be compromised (perhaps this would
> be
> better than an overwrite). One of the original constraints when the
> TXTRenderer was developed was that the text output fit within fixed page
> sizes (fixed number of rows/columns). Depending on your application, this
> may not be important. Perhaps a "mode" could be added to preserve text
> (versus preserving layout). The only consolation I have had with regard to
> the TXTRenderer is that I find its output superior to many commercial
> applications' lame text output (IMHO).
> Art
> -----Original Message-----
> From: Illiano, Vincent [mailto:[EMAIL PROTECTED] 
> Sent: Monday, June 16, 2003 2:28 PM
> To: Illiano, Vincent
> Subject: Ascii file generation questions
> > Hi fellow Fop'ers,
> > 
> > I've built a dynamic document generation system using FOP.  I'm 
> > currently using version 0.20.4.  The 2 supported output formats are 
> > PDF and ASCII text.  I know that the ASCII renderer was never meant to 
> > be production quality.  However, with some tweaking, I have been able 
> > to get out of it what I need.  I'm including an example text output 
> > file that was generated by my system using FOP.
> > 
> > The main problem that I have found with the text output generation is 
> > the line-overwriting problem.  However, I have been able to fix this 
> > for the most part by adding extra space before the blocks where the 
> > overwriting occurs.  For example:
> > 
> > change
> >     <fo:block>Procedure Comment</fo:block>
> > to
> >     <fo:block space-before="10.5pt">Procedure Comment</fo:block>
> > 
> > often fixes the overwriting problem that may occur in a particular 
> > paragraph of text.
> > 
> > Is there someone on this list who can explain to me why the 
> > overwriting problem occurs and if it's something that could be fixed?  
> > I can volunteer to dig in and do it myself with just a little 
> > guidance.  Also, is the text output feature planned in the redesign?  
> > I really hope so, because I think text is a valid output format.  
> > Again, I can volunteer to work on that feature if it's not already in 
> > the plan.
> > 
> > Here is the example text file.  Thanks, -Vincent
> > 
> >  <<vreport.txt>>
> > 

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

Reply via email to