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: [email protected]
For additional commands, e-mail: [email protected]
