Hi Sergey, unfortunately, you didn't notice the TXTRenderer that was in 0.20.5 . The text renderer seems to work fine for many people who work with FOP 0.20.5. IMO it should be simple to port that renderer to FOP Trunk. The TXTRenderer currently found in FOP Trunk is only an empty shell which needs to be filled. I'd investigate that before doing any serious coding on a completely new TextRenderer. Please have a look at TXTRenderer and get back to us so we can sort out any details. The old TXTRenderer is capable of creating good output without any special handling in the area tree. You will also find discussion snippets around the TXTRenderer in the mailing list archives which should give you an idea about its design.
BTW, I'm glad that you're going to reintroduce the TextRenderer. AFAIK, there's still a open issue with a patch  where I asked you to send in an ICLA so I can commit the patch. So far, I haven't seen an ICLA being recorded with your name.  http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/branches/fop-0_20_2-maintain/src/org/apache/fop/render/txt/  http://issues.apache.org/bugzilla/show_bug.cgi?id=36480 On 17.09.2005 12:35:56 Sergey Simonchik wrote: > Hi, > > We've put mind to txt-rendering. :) Evidently converting to txt isn't > implemented yet. So, before code writing, it will be useful to discuss > different approaches of implementing it. By this moment we've found 3 > possible basic approaches. > Here they are: > 1) > TxtRender extends AbstractRender and try to render AbstractTreeModel to txt > format. This approach similar to PDF. But unfortunately txt format is much > less flexible than PDF. > Thus we need to modify area tree model in order to render it to txt format. > > Details: > TxtRender extends AbstractRender and overloads some methods which process > model. > > 2) > The second idea is similar to RTF approach. TxtHandler extends > FOEventHandler and handles formatting objects by his own without > AreaTreeModel. > This doesn't allow us to use advantages of LayoutManager, for example lines > fragmentation. > > 3) > The third approach consist of modifying formatting objects before > constructing area tree model. > > After getting formatting objects we make a refinement consisting of some > procedures. One of them is converting font's attributes to default value > which most appropriate for txt render. As we have already realized its > Courier 10. > > Details: > TxtHandler extends AreaTreeHandler and overloads only one method - > endPageSequence where refinement takes place. > TxtRender extends AbstractRender and overloads some methods which process > model. > But unlike first approach we have to do much less because LayoutManager gets > modified formatting objects and returns better result. > > We started developing third approach. > > Good luck. Jeremias Maerki