>>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.
I understand but if we want to be strict, XSLT only transform from XML to
another format (often XML but also Text). In my case wiki syntax is not XML
so we could say it shouldn't be transformed through XSLT.
Regards,
Kalgon
Glenn Adams-2 wrote:
>
> 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
> <edoug...@blockhouse.com>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:cr...@maden.org]
>> Sent: Tuesday, June 14, 2011 9:44 AM
>> To: fop-users@xmlgraphics.apache.org
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31843807.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
