I'm not sure where I suggested it's not appropriate to consider an extension. I believe I suggested as you say it might be better to rip out the function of allowing XML and XSL as input, to provide a separate convenience jar and/or the code to embed that process, since creating the FO doesn't involve any fop classes. I already split out that process in my embedded code if you want to see the 2 step. I don't know what the wiki text looks like or how common it might be for users to want to use it as input. If it has a standard format which can be translated to FO tags and someone wants to write the code to translate it, it would be nice if code like that could be included as a separate download on the fop site. I'm not sure what you consider an extension (plugin?) if they're normally compiled into the fop.jar, if they're separate jars to download to call as separate tasks, or if they're separate jars to put on the classpath to accept different types of values from the mainline fop (ie the -xml -xsl tags)? I think anything unique to one type of input or output can be a separate jar with the code kept separately whether you call them extensions, plugins, or subprojects. They can either be documented second step processes (output of this = input of that) or extension options (use -xml and -xsl tags to send input as xml instead of the -fo tag).
________________________________ From: Glenn Adams [mailto:[email protected]] Sent: Tuesday, June 14, 2011 10:47 AM To: [email protected] Subject: Re: FOP Extension to handle Wiki Syntax You know, given the time spent answering questions about XSL and the XML+XSL -> XSL-FO front-end ("convenience mechanism") in FOP, I sometimes wonder if it would be better to rip out that function. Perhaps then folks would understand better that FOP is fundamentally an XSL-FO -> output format processor. As to the original comment, I agree with Eric that is is not appropriate to consider an FOP extension to accommodate semantics that apply to the XML+XSL -> XSL-FO 'convenience mapping' mechanism. G. On Tue, Jun 14, 2011 at 8:29 AM, Eric Douglas <[email protected]> wrote: It could handle any format you want to write your input in as long as it can be translated to FO. If another format is commonly used for generating FOP input someone would just have to write an input translator extension. FOP doesn't even do anything with XML/XSL. It accepts input as XML/XSL as a courtesy extension. I wrote a transform with embedded code starting with data in XML using an XSL to translate it. Then I figured out how to generate FO and split that out as a separate step. That uses the javax transformer. That step doesn't use any FOP objects. If you think about it, output could be considered extensions also. The main task of the FOP is to input FO and generate the IF. Once that's laid out it can take various renderers and generate output so you have a PDF extension, a PNG extension, a TIFF extension, etc. They don't need to be in the FOP package. Someone who only wants to create PDFs doesn't need any classes which create PNGs. If you could break all the extensions out into subprojects it would make it a few extra steps to download but it would be simplified into smaller jars which of course load faster if you don't need them all. -----Original Message----- From: Christopher R. Maden [mailto:[email protected]] Sent: Tuesday, June 14, 2011 9:44 AM To: [email protected] Subject: Re: FOP Extension to handle Wiki Syntax On 06/14/2011 07:25 AM, kalgon wrote: > Yes I could transform the XML prior to rendering it to PDF but that > wouldn't be as nice and clean as an extension which would take care of > everything. Moreover, an extension can be reused whereas > pre-transforming the XML would require a specific XSLT for each XML > schema... definitely not the way I want to go. Except that's how XSL works, and what FOP implements. FOP takes exactly[*] 1 kind of input: the FO markup in XML defined by the XSL Recommendations. Nearly all FOP users, as well as users of other XSL formatters, transform their source either with XSLT or some other tool into FO for presentation to the formatter. If FOP supports MediaWiki syntax natively, why not MoinMoin or some other wiki? Why not HTML, DocBook, DITA, CALS, ...? ~Chris [*] approximately -- Chris Maden, text nerd <URL: http://crism.maden.org/ > "Before I built a wall I'd ask to know / What I was walling in or out, / And to whom I was like to give offence." - RF, Mending Wall GnuPG Fingerprint: C6E4 E2A9 C9F8 71AC 9724 CAA3 19F8 6677 0077 C319
