Thanks for your answer,
Today, I made a working prototype with Saxon by using
http://www.saxonica.com/documentation/extensibility/integratedfunctions.xml
ExtensionFunctionCall s. It's a bit complicated since Saxon-HE 9.3 (or was
it 9.2?) dropped support for calling static java methods from the
stylesheet. It's also a pity that javax.xml.transform API does not provide a
standard way to register additional functions, I will have to make specific
extensions for Xalan AND Saxon and usage within stylesheets will differ too
based on the transformer library you will use.
Well, I know those problems are not directly related to FO(P) but I just
wanted to rant a bit about it.
Regards,
Kalgon
Andreas L. Delmelle wrote:
>
> On 14 Jun 2011, at 16:46, Glenn Adams 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.
>
> FOP did start that way, if I recall correctly. There was a time when
> including the possibility to feed XML+XSLT as input was considered a big
> win. I actually think going back makes little sense, especially given that
> the usage pattern for embedding is basic JAXP. Even if you feed FOP plain
> FO, an identity transformation is used nowadays, also when invoking via
> the CLI.
> Way back when, using the CLI with plain FO actually did not use the XSLT
> processor at all, just the XML parser.
>
> Another point would be that XSL-FO itself defines nearly all its examples
> in terms of XSLT that transforms semantic XML to FO... *shrug*
> It is easy to see how newcomers get confused. Ultimately, we could just
> respond with a link to the website, where it is darn' well explained what
> the recommended practice is in case of problems (i.e. submit FO, not XSLT;
> if the problem is XSLT, go to Mulberry etc.).
> Nonetheless, I'll probably never get tired of pointing it out to people
> --even if they do seem to lack the most basic web browsing skills
> sometimes... ;-)
>
> On 14 Jun 2011, at 12:09, kalgon wrote:
>
>> <snip />
>> What I would like to know is how I can build a tree of FONodes (blocks,
>> text, table...) programmatically while parsing my wiki text and feed that
>> tree to the FOP engine. I've been looking at ElementMapping, XMLHandler
>> and
>> the likes but I can't get a good grip at how those are working.
>>
>> If somebody could point me to a good and complete tutorial on FOP
>> extensions
>> or send me a nice example of how to do it, that would help me a lot!
>
> In this particular case, I would agree with the assessment that a FO
> extension would not be the most efficient/productive choice. While I can
> explain how to insert a new Block into the stream, I still would not
> encourage it. The quick and dirty approach, with probably the highest
> probability of success, would be to just send the appropriate SAX events
> back to the FOTreeBuilder.
> So, your code would have to be full of:
>
> Attributes myAttrs = new AttributesImpl();
> myAttrs.addAttribute("", "font-weight", "font-weight", "CDATA", "bold");
> ...
> builder.startElement(FO_URI, "block", "fo:block", myAttrs);
> ...
> builder.endElement(FO_URI, "block", "fo:block", myAttrs);
>
> I am not entirely certain it will always work, but I don't immediately see
> another way that would cheaply allow you to get potential property
> inheritance right, or have your content behave properly if it is contained
> in a fo:marker...
>
> This shows that FOP's API simply isn't designed with that in mind.
> Internally, it is meant to parse formatting objects from XML source. FO
> extensions only allow you to go so far. The extension mechanism is mainly
> meant to allow you to handle custom, foreign XML (= non-FO, e.g. to plug
> in a handler for your custom child object of fo:instream-foreign object;
> prime examples SVG, MathML, Barcode4J...). Translating flat text markup
> into FO (or more generally: XML), not so much.
>
> Don't get me wrong. I like the whole idea of being able to translate
> MediaWiki fragments directly into FO. Seems a very useful thing to have,
> however...
>
> Given the power of XSLT/XPath 2.0 to handle regex processing of unparsed
> text and consistent generation of valid XML(FO) nodes (even when the
> nesting levels get too difficult to follow for the human mind and its
> programming logic), this seems like THE weapon of choice for such a job.
> With a bit of imagination, one can easily keep this generic enough to work
> for a multitude of source XMLs. Just write a small stylesheet library to
> translate arbitrary MediaWiki markup into the corresponding FO syntax, and
> plug it into the main stylesheet. Sequences and xsl:functions are truly
> powerful stuff!
>
> If you feel generous, make it publicly available for everyone to try
> out/correct/extend... I'm quite sure it will get all the attention it
> deserves. We would gladly link to it from our website (or accept a
> contribution on the Wiki ;-))
>
>
> Regards
>
> Andreas
> ---
> ---------------------------------------------------------------------
> 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-tp31841403p31853660.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
