Re: [RTF] jfor progress
Hi Victor, Thanks for your work! ...I *really* like the approach of having the independent package, and recommend that we use the same approach for other StructureRenderers, including MIF Yes, the StructureRenderer interface nicely decouples these renderers from the rest of FOP. Maybe a new build target that creates a standalone fop-rtflib.jar would be good? I'd still keep rtflib in the main fop.jar, but offer a standalone rtflib in addition. Note that the interest for a MIF renderer is probably lower than it was before, as newer versions of FrameMaker can import XML directly and combine it with (homegrown) style mappings. ...1. How much does the API need to be protected? Are we pretty free to change it as we see fit, or will that mess up existing jfor users too much? ... It is hard to say, although there have been several thousand downloads of jfor since it was created, the feedback from users is comparatively very small so we don't have a precise idea of how many people are doing what. I know some people are using the RTF API directly, but have no idea how many. I think you can go ahead with API changes that improve the library or are required for refactoring (see below comments about RtfText). ...Specifically, I am tempted to move some of the constants (alignment and indentation for example) in RtfText to RtfParagraph for a more intuitive interface Makes sense. An alternative would be to define constants in interfaces (RtfAlignConstants, RtfParaConstants etc) to group them, and have the classes that use them implement these interfaces to make the values directly available. This would be more compatible with the existing API I think. ...what do you think of the idea of building a Border object with those axes as properties... Sounds good. IIRC this border stuff has been contributed in small bits and pieces to jfor, with no real design, so some refactoring is welcome. ...I'm guessing there are some other concepts that will benefit from such an approach as well Yes, you've probably seen code that is too linear and could benefit from better object design. ...have changed RtfParagraph.writeRtfPrefix() to write the text attributes as well as the paragraph attribute If one can still set text attributes on individual text runs inside a paragraph as well, then fine. I'm not happy with the current design of RtfText embedded in RtfParagraph - although this maps well to the XSL-FO model (elements), it does not map well to the RTF model (text runs I think, but still somewhat mysterious after all these years ;-). This causes problem in jfor where nested paragraphs and inlines are sometimes output in the wrong order. I think a flatter design of the RtfText vs. RtfParagraph model would help. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [RTF] jfor progress
Bertrand Delacretaz wrote: Maybe a new build target that creates a standalone fop-rtflib.jar would be good? I'd still keep rtflib in the main fop.jar, but offer a standalone rtflib in addition. +1 Note that the interest for a MIF renderer is probably lower than it was before, as newer versions of FrameMaker can import XML directly and combine it with (homegrown) style mappings. Good point. However, I know that I have some interest in it, because of the ability to use XSLT for the style mappings instead of Frame. To make this work, we need (and probably need anyway, and can probably expect to see in a future FO standard) the ability to create styles in FO. I may propose such an extension in the future, but I'll probably defer it as long as possible in the hopes that the FO standard will get there first. BTW, I have a big beef with Adobe (FrameMaker) and Corel (WordPerfect) for claiming that their products support XML, when they use proprietary character sets, and have *no* way to deal with Unicode. An alternative would be to define constants in interfaces (RtfAlignConstants, RtfParaConstants etc) to group them, and have the classes that use them implement these interfaces to make the values directly available. This would be more compatible with the existing API I think. Good idea. I'll think on this a bit. ...have changed RtfParagraph.writeRtfPrefix() to write the text attributes as well as the paragraph attribute If one can still set text attributes on individual text runs inside a paragraph as well, then fine. Yes. I'm not happy with the current design of RtfText embedded in RtfParagraph - although this maps well to the XSL-FO model (elements), it does not map well to the RTF model (text runs I think, but still somewhat mysterious after all these years ;-). This causes problem in jfor where nested paragraphs and inlines are sometimes output in the wrong order. I think a flatter design of the RtfText vs. RtfParagraph model would help. Yes, I ran into this in what I thought would be a trivial exercise of adding background colors to paragraphs. If you set the color at the beginning of the paragraph, it affects the rest of the document. My tentative solution was to simply keep track of the state of the concept on the FOP side, and look for changes. However, I expect that we can throw more of this burden onto the RTFLib side, perhaps with a configurable option that could either favor an element-driven approach or a text-run-driven approach. The \par vs. \pard might help in this regard. It sounds like we are on the same page so far. Please let me know if you see me heading off in a bad direction. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] jfor progress
--- Victor Mote [EMAIL PROTECTED] wrote: Question for Everyone: I *really* like the approach of having the independent package, and recommend that we use the same approach for other StructureRenderers, including MIF, and the yet-unborn merely-glimmers-in-my-mind RawText and TeX renderers. Any comments? Sounds good, but to help me better understand, in the document you wrote: Q It does not require FOP as a front-end, nor does it even require XSL-FO for input. /Q Precisely, what does it require for input? Will it accept XSL-FO for input? I would put in a sentence or two explaining what its input is. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] jfor progress
--- Glen Mazza [EMAIL PROTECTED] wrote: --- Victor Mote [EMAIL PROTECTED] wrote: Question for Everyone: I *really* like the approach of having the independent package, and recommend that we use the same approach for other StructureRenderers, including MIF, and the yet-unborn merely-glimmers-in-my-mind RawText and TeX renderers. Any comments? Sounds good, but to help me better understand, in the document you wrote: Q It does not require FOP as a front-end, nor does it even require XSL-FO for input. /Q Precisely, what does it require for input? Will it accept XSL-FO for input? I would put in a sentence or two explaining what its input is. Glen Restating, I realize it does not contain its own XSLFO processor, but a short statement at the beginning (in addition to your detailed summary later on) of what it *is* fed may help emphasize the black box nature (i.e., what you're trying to highlight) of this independent package. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
