On 23.05.2006 08:02:50 b.ohnsorg wrote: > > ----- original Nachricht -------- > > Betreff: Re: RTF, nested tables, context enhancement - status > Gesendet: Mo 22 Mai 2006 22:30:07 CEST > Von: "Jeremias Maerki"<[EMAIL PROTECTED]> > > > page-number-citation and page numbering: Both work to at least a certain > > degree. Can you elaborate on the problems you're seeing? > RTF does not know any «citation», so you need to write a character '2', > if you want a link to display a page information refering to page '2'. > For example an index at the end of the document does not know, which > page explains «Barcode» and all links will show a question mark.
That's not correct. RTF has support for page number citations. You should take a lot at the RTF specification and create an RTF file in MS Word with references so you see how this should be implemented. > I thought about that last night (while cruising through the > PDF-renderer to compare my table width «guessing» with the already > implemented one) > and draw the following conclusion: > > Fact 1: RTF knows page breaks Wrong. RTF can contain hard page breaks but doesn't have to. > Fact 2: RTF is page-oriented Wrong. RTF is a flow-oriented format. Microsoft Word is responsible for the page break decisions unless you add hard page breaks. > Fact 3: RTF aligns elements absolute Yes. > Fact 4: RTF does not know anything about the document's structuring Depends on what you mean by structure. RTF supports styles which allow some kind of structuring. > Conclusion: RTF differs not that much from PDF-rendering (only written tokens > are a bit different) > -> Use the PDF-layout management system and add a RTF-writer. So RTF > would look exactly like all PDFs. And there's only a slight difference > from Office-generated RTFs: page breaks after every page. That would defeat the purpose of the current RTF output support. The clue is that you can edit the generated file and then print it. If you predefine the page breaks you make the editing a lot harder for the end-user. If you don't need RTF editing, then don't generate RTF because PDF offers much better quality. > > > > What's exactly the problem with graphics? We've got pretty good support > > for many cases, even SVG now. > I was only talking about the current RTF export. AFAIK GIFs are not rendered > (there was an annoying exception string inside the document). > > > GIF: The LZW patents are expired but still it's a good idea to forget > > GIF. The legal side is still less than clear. > But PDF «understands» GIFs, so I can use them. Should be the same with > RTF, and the only thing I'll do is reading them and transform into a > RTF-compatible format...if it's not legal I won't do this... PDF doesn't understand GIFs. Images are converted from GIF to a generic bitmap format supported by PDF. In the case of RTF output this code hasn't been written, yet. Patches welcome. > > RTF does support referenced images. > So there ought to be a switch (render to the document, use references) ...if someone implements that switch. > > Over all, your post seems to address topics which, as far as I know, are > > mostly solved, so I'm not really sure what you're after. Maybe if you'd > > show the problems you're trying to address with examples.... > I only wanted to check any progress, maybe I forgot some important fact > or any discussion. But the referencing of page-number-citation is one > problem (we already discussed this in February), nesting tables, > indenting...everything which needs structures inside structures (a > block inside a block, a table inside a block, a block inside a table...) You can see that there is still some work ahead. Some features will probably never be implemented because RTF is such a crappy format. I doubt we will ever get 100% functionality on nested tables. > > Anyway, we're looking forward to any patches against FOP SVN Trunk you > > might have. At any rate, you'd have problems committing anything to the > > repository without write access. That privilege will need to be earned > > first. ;-) > I know, therefore the review-strategy and «restructuring» the > RTF-renderer will break it for a while (compiles, but does not produce > any usable document). Before you take the RTF handler (not renderer!) apart you should understand RTF first. It seems you have a few things to catch up. As I said above, converting the RTFHandler into a Renderer defeats the purpose of the RTF format in the first place. > By now it's just transforming FOP-events to > RTF-tags and I ran into > problems which were solved with the new > FOP-code (more effective > memory usage) but seemed to be necessary (e.g. a table's > width can only be determined if all columns were parsed, therefore you > need to save previous column objects and by nesting tables it gets > quite heavy [tried to experiment a bit with auto-table-layout, so you need all > the rows, too]) Yes, the layout engine (for page-oriented documents) contains code that more or less needs to be duplicated for RTF. Maybe some of it can be extracted so it can be used for both kinds of conversions (to flow-oriented formats like RTF (FOEventHandler) and to page-oriented formats like PDF and PostScript (Renderers). Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
