RE: FOP Extension to handle Wiki Syntax

2011-06-15 Thread Theresa Jayne Forster
We see what you are trying to do,  what would be probably better rather than 
creating an extension, 
How about a more helpful / generic pre-processor 

Wiki -- XML
And then you can add your own pre-processor extensions to say add 
BBCode-XML

Then you can use your wiki-XML to change the wiki page into a valid XML 
document to be transformed into FO by xsl and then to pdf.

Example:
**this is a header**   --  para style=header2this is a header/para


Kindest regards


Theresa Forster
Senior Software Developer



-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: FOP Extension to handle Wiki Syntax

2011-06-15 Thread kalgon

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 

RE: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Theresa Jayne Forster
Can't you just XSLT the incoming document ?


Kindest regards


Theresa Forster
Senior Software Developer
-Original Message-
From: kalgon [mailto:kal...@hotmail.com] 
Sent: 14 June 2011 11:09
To: fop-users@xmlgraphics.apache.org
Subject: FOP Extension to handle Wiki Syntax


Hi,

I would like to write a FOP extension to render text written in wiki syntax:

fo:block
fopwiki:wiki value={/root/description/text()} /
/fo:block

root
description
= title =
* item
* item
/description
/root

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!

Thanks,

Kalgon

-- 
View this message in context:
http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p3184140
3.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



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1382 / Virus Database: 1511/3683 - Release Date: 06/05/11
Internal Virus Database is out of date.



-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



RE: FOP Extension to handle Wiki Syntax

2011-06-14 Thread kalgon

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.

Regards,

Kalgon


Theresa Jayne Forster wrote:
 
 Can't you just XSLT the incoming document ?
 
 
 Kindest regards
 
 
 Theresa Forster
 Senior Software Developer
 -Original Message-
 From: kalgon [mailto:kal...@hotmail.com] 
 Sent: 14 June 2011 11:09
 To: fop-users@xmlgraphics.apache.org
 Subject: FOP Extension to handle Wiki Syntax
 
 
 Hi,
 
 I would like to write a FOP extension to render text written in wiki
 syntax:
 
 fo:block
 fopwiki:wiki value={/root/description/text()} /
 /fo:block
 
 root
 description
 = title =
 * item
 * item
 /description
 /root
 
 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!
 
 Thanks,
 
 Kalgon
 
 -- 
 View this message in context:
 http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p3184140
 3.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
 
 
 
 -
 No virus found in this message.
 Checked by AVG - www.avg.com
 Version: 10.0.1382 / Virus Database: 1511/3683 - Release Date: 06/05/11
 Internal Virus Database is out of date.
 
 
 
 -
 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-tp31841403p31841886.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



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Christopher R. Maden
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



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread kalgon

But then, what is the purpose of extensions? There are several extensions
which generate barcodes (barcode4j, zxing-fop-qrcode)... so if I follow your
reasoning, we should not use those and rather pre-generate the images and
use fo:external-graphic, right?

I don't see what you're talking about FOP supporting natively MediaWiki. How
does it support MediaWiki?

What I want to do is create an extension which can create a subtree of the
FO tree (and reusing basic nodes like Block, Table, FOText) but I can't find
any documentation explaining how to do that (if it's possible). I'd prefer
an extension doing the wiki-fo transformation in one pass instead of having
to write two XSL's with intermediate results:

root
description
  * item1
  * item2
/description
/root

transformed to:

root
description
fo:list-block
fo:list-item.../fo:list-item
fo:list-item.../fo:list-item
/fo:list-item
/description
/root

and then only transformed into full fo:

fo:root
   ...
/fo:root

I prefer having a self-contained extension which does all the work for me.

Regards,

Kalgon


Christopher R. Maden wrote:
 
 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
 
 
 

-- 
View this message in context: 
http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31843185.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



RE: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Eric Douglas
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



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Christopher R. Maden
On 06/14/2011 10:15 AM, kalgon wrote:
 But then, what is the purpose of extensions? There are several
 extensions which generate barcodes (barcode4j, zxing-fop-qrcode)...
 so if I follow your reasoning, we should not use those and rather
 pre-generate the images and use fo:external-graphic, right?

There isn’t anything in the XSL Recommendation about barcodes, so a
barcode extension made sense.  True, graphics could have been used, but
barcodes make a lot of sense as formatting artifacts as well.

The MediaWiki markup for which you’re asking involves headings,
paragraphs, and lists, which are already supported by XSL.  No extension
is needed to provide the functionality.

 I don't see what you're talking about FOP supporting natively
 MediaWiki. How does it support MediaWiki?

It doesn’t.  That’s what you are asking for.  (Remember that “wiki” is a
concept of user-edited Web sites; specific kinds of wiki software use
different markup.  Wikipedia and the other Wikimedia Foundation sites
use software called MediaWiki.)

 What I want to do is create an extension which can create a subtree
 of the FO tree (and reusing basic nodes like Block, Table, FOText)
 but I can't find any documentation explaining how to do that (if it's
 possible). I'd prefer an extension doing the wiki-fo transformation
 in one pass instead of having to write two XSL's with intermediate
 results:
 I prefer having a self-contained extension which does all the work
 for me.

That kind of encapsulated transformation makes a lot of sense.  However,
like other pre-FO transformations, it does not belong in FOP.  FOP
starts with XSL FO markup; transformations come before that.

~Chris
-- 
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



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Glenn Adams
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.comwrote:

 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




Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Sergiu Dumitriu

On 06/14/2011 04:46 PM, 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.

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.


On the other hand, XSLT is not the best language for implementing wiki 
syntax rendering either.


An alternative to writing a FOP extension would be to write an 
XSLT/XPath extension that handles the wiki syntax; instead of simply 
copying the textual content of the source element, do something like: 
xsl:value-of select=wiki:render(.)/.


http://xml.apache.org/xalan-j/xpath_apis.html#functionresolver explains 
a bit what's needed to write a custom XPath function. You could use an 
existing Java library for wiki syntax rendering, such as 
http://rendering.xwiki.org/



G.

On Tue, Jun 14, 2011 at 8:29 AM, Eric Douglas edoug...@blockhouse.com
mailto: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
mailto:cr...@maden.org]
Sent: Tuesday, June 14, 2011 9:44 AM
To: fop-users@xmlgraphics.apache.org
mailto: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



--
Sergiu Dumitriu
http://purl.org/net/sergiu/

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread kalgon

Thanks for the explanation about MediaWiki: the term natively led me to think
that FOP already had support for MediaWiki syntax. As I was talking about an
extension, I didn't see how it could be done natively.

So if the WIKI-FO-XML transformation does not belong to FOP, it surely
belongs to the transformation part which comes before rendering. But then, I
should use Saxon or Xalan specific extensions or does javax.xml.transform
provide an unified way to do such a thing? I have currently no idea on how
to do that but I suppose the wiki parsing routine will have to be called
from inside the stylesheet and I have had bad experiences trying to call
java code from xslt. And if javax.xml.transform does not provide a standard
way to do that, I will have to create specific extensions for each xslt
library (Saxon and Xalan). If I could do it directly through a FOP
extension, I would not have those problems.

So, now that I understand that such a processing is better done outside FOP,
do you think there's a way I could do it inside though an extension? :-)

If somebody has a simple example of how an extension could programmatically
create a FOText inside a Block, I think I could handle the rest.

Regards,

Xavier


Christopher R. Maden wrote:
 
 On 06/14/2011 10:15 AM, kalgon wrote:
 But then, what is the purpose of extensions? There are several
 extensions which generate barcodes (barcode4j, zxing-fop-qrcode)...
 so if I follow your reasoning, we should not use those and rather
 pre-generate the images and use fo:external-graphic, right?
 
 There isn’t anything in the XSL Recommendation about barcodes, so a
 barcode extension made sense.  True, graphics could have been used, but
 barcodes make a lot of sense as formatting artifacts as well.
 
 The MediaWiki markup for which you’re asking involves headings,
 paragraphs, and lists, which are already supported by XSL.  No extension
 is needed to provide the functionality.
 
 I don't see what you're talking about FOP supporting natively
 MediaWiki. How does it support MediaWiki?
 
 It doesn’t.  That’s what you are asking for.  (Remember that “wiki” is a
 concept of user-edited Web sites; specific kinds of wiki software use
 different markup.  Wikipedia and the other Wikimedia Foundation sites
 use software called MediaWiki.)
 
 What I want to do is create an extension which can create a subtree
 of the FO tree (and reusing basic nodes like Block, Table, FOText)
 but I can't find any documentation explaining how to do that (if it's
 possible). I'd prefer an extension doing the wiki-fo transformation
 in one pass instead of having to write two XSL's with intermediate
 results:
 I prefer having a self-contained extension which does all the work
 for me.
 
 That kind of encapsulated transformation makes a lot of sense.  However,
 like other pre-FO transformations, it does not belong in FOP.  FOP
 starts with XSL FO markup; transformations come before that.
 
 ~Chris
 -- 
 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
 
 
 

-- 
View this message in context: 
http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31843733.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



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread kalgon

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.comwrote:
 
 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



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread kalgon

 An alternative to writing a FOP extension would be to write an 
 XSLT/XPath extension that handles the wiki syntax; instead of simply 
 copying the textual content of the source element, do something like: 
 xsl:value-of select=wiki:render(.)/. 

That's the practical solution but I always try to avoid manipulating XML
like Strings (there could be namespace issues).

I think that if I can't write an extension to do what I want, I will go that
way.

Regards,

Kalgon


Sergiu Dumitriu-2 wrote:
 
 On 06/14/2011 04:46 PM, 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.

 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.
 
 On the other hand, XSLT is not the best language for implementing wiki 
 syntax rendering either.
 
 An alternative to writing a FOP extension would be to write an 
 XSLT/XPath extension that handles the wiki syntax; instead of simply 
 copying the textual content of the source element, do something like: 
 xsl:value-of select=wiki:render(.)/.
 
 http://xml.apache.org/xalan-j/xpath_apis.html#functionresolver explains 
 a bit what's needed to write a custom XPath function. You could use an 
 existing Java library for wiki syntax rendering, such as 
 http://rendering.xwiki.org/
 
 G.

 On Tue, Jun 14, 2011 at 8:29 AM, Eric Douglas edoug...@blockhouse.com
 mailto: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
 mailto:cr...@maden.org]
 Sent: Tuesday, June 14, 2011 9:44 AM
 To: fop-users@xmlgraphics.apache.org
 mailto: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
 
 
 -- 
 Sergiu Dumitriu
 http://purl.org/net/sergiu/
 
 -
 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-tp31841403p31843863.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



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Christopher R. Maden
On 06/14/2011 11:23 AM, kalgon wrote:
 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.

Text nodes are part of XML... XSLT can handle processing the contents of
those text nodes.

However, it’s not always the best tool for doing that.  I would probably
write something in your language-of-choice that takes in an XML tree and
writes it out identically, except for upgrading the free-text markup.
There are converters out there to do it... the Freebase BFG project used
one written by one of the original Wikipedia markup designers... see
URL: https://secure.wikimedia.org/wikipedia/en/wiki/User:Magnus_Manske .

This has gotten off-topic for FOP.  If you decide to do this in XSLT,
see URL: http://www.mulberrytech.com/xsl/xsl-list/ .  Otherwise, see
the discussion fora for whatever other programming language you’re using.

~Chris
-- 
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



RE: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Eric Douglas
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:gl...@skynav.com] 
Sent: Tuesday, June 14, 2011 10:47 AM
To: fop-users@xmlgraphics.apache.org
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 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

Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Rob Sargent
We have success editing the fo programmatically, parsing out some 
special strings our application embeds in the xml/text nodes.  Not 
something we're necessarily proud of, but it works perfectly well.


On 06/14/2011 09:54 AM, kalgon wrote:

You're right, I shouldn't have been talking so much about the context of what
I want to achieve, the only question that matters to me is: is it possible
for an extension to programmatically add standard FO nodes to the main FO
tree, if yes how?. That is all I want to know and until now, nobody has
been able to answer that question. I see that FOP does have a lot of
extension points but very few documentation about their usage, and I don't
mind it this is not the correct way of doing things. I never started the
debate about that, I just wanted a simple plain answer to my question.

Regards,

Kalgon


Christopher R. Maden wrote:

On 06/14/2011 11:23 AM, kalgon wrote:

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.

Text nodes are part of XML... XSLT can handle processing the contents of
those text nodes.

However, it’s not always the best tool for doing that.  I would probably
write something in your language-of-choice that takes in an XML tree and
writes it out identically, except for upgrading the free-text markup.
There are converters out there to do it... the Freebase BFG project used
one written by one of the original Wikipedia markup designers... see
URL: https://secure.wikimedia.org/wikipedia/en/wiki/User:Magnus_Manske.

This has gotten off-topic for FOP.  If you decide to do this in XSLT,
seeURL: http://www.mulberrytech.com/xsl/xsl-list/.  Otherwise, see
the discussion fora for whatever other programming language you’re using.

~Chris
--
Chris Maden, text nerdURL: 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



Re: FOP Extension to handle Wiki Syntax

2011-06-14 Thread Glenn Adams
Of course, an extension can do anything you want. But you have to define it
and write the Java that implements it.

Again, I question the basis of your question. The XSL-FO tree starts out as
an XML document, having the root node of fo:root, and adhering to the XSL-FO
specification. You should write an external tool that takes whatever format
you like (wiki) and translates it to XSL-FO, then feed that to FOP.

Forget about the XML/XSLT to XSL-FO front-end preprocessor in FOP. If you
want to define an extension to do what you want in FOP, you are basically
asking for an extension to the front end XML/XSLT processing convenience
mechanism in FOP.  However, this is based on off-the-shelf XML and XSLT
tools (xerces, xalan). So basically, you are asking for an extension to one
of these latter tools, not an extension for XSL-FO.

G.

On Tue, Jun 14, 2011 at 9:54 AM, kalgon kal...@hotmail.com wrote:


 You're right, I shouldn't have been talking so much about the context of
 what
 I want to achieve, the only question that matters to me is: is it possible
 for an extension to programmatically add standard FO nodes to the main FO
 tree, if yes how?. That is all I want to know and until now, nobody has
 been able to answer that question. I see that FOP does have a lot of
 extension points but very few documentation about their usage, and I don't
 mind it this is not the correct way of doing things. I never started the
 debate about that, I just wanted a simple plain answer to my question.

 Regards,

 Kalgon


 Christopher R. Maden wrote:
 
  On 06/14/2011 11:23 AM, kalgon wrote:
  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.
 
  Text nodes are part of XML... XSLT can handle processing the contents of
  those text nodes.
 
  However, it’s not always the best tool for doing that.  I would probably
  write something in your language-of-choice that takes in an XML tree and
  writes it out identically, except for upgrading the free-text markup.
  There are converters out there to do it... the Freebase BFG project used
  one written by one of the original Wikipedia markup designers... see
  URL: https://secure.wikimedia.org/wikipedia/en/wiki/User:Magnus_Manske.
 
  This has gotten off-topic for FOP.  If you decide to do this in XSLT,
  see URL: http://www.mulberrytech.com/xsl/xsl-list/ .  Otherwise, see
  the discussion fora for whatever other programming language you’re using.
 
  ~Chris
  --
  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
 
 
 

 --
 View this message in context:
 http://old.nabble.com/FOP-Extension-to-handle-Wiki-Syntax-tp31841403p31844121.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