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