[xwiki-users] Using a commercial pdf-rendering library
Hi, we want to modify the pdf-export by using a commercial pdf-rendering library. As so far the pdf-export is located in the xwiki-platform-oldcore package, I suppose the reengineering is still pending. Because of that I wanted to ask how is the future strategy for the pdf-export? How can we integrate our pdf-export to be prepared for future modification? Thanks and regards, Josef -- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Josef, On Jul 1, 2013, at 10:45 AM, jhaimerl <[email protected]> wrote:
Hi,
we want to modify the pdf-export by using a commercial pdf-rendering library. As so far the pdf-export is located in the xwiki-platform-oldcore package, I suppose the reengineering is still pending. Because of that I wanted to ask how is the future strategy for the pdf-export? How can we integrate our pdf-export to be prepared for future modification?
The long term future is to have the PDF export done using the Rendering engine as a Renderer (ie ability to transform XDOM into PDF). I've even started a branch on this at https://github.com/xwiki/xwiki-rendering/tree/itext-pdf-renderer Now this branch is more an experiment at this stage since using iText is very nice but has 2 important drawbacks: PDF styling and exporting HTML (RawBlock with HTML). But even if we don't use iText we could still move our current PDF export code in a Renderer and implement the current pipeline (syntax --> HTML --> PDF, as described at http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HCustomizi... There's no defined roadmap to do this at this point. Currently you'll need to modify ExportAction.export(). Thanks -Vincent
Thanks and regards,
Josef
Hi Vincent, thanks for your reply. As there is nothing explicit defined on the roadmap, what do you think about a general interface for replacing the pdf renderering library? We defenetly will work internally on the PDF-Export and I think if we spend time on this, we could do it in a way the community could profit of. So what's your oppinion? How could the design be? Thanks Josef -- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Josef, On Jul 8, 2013, at 8:28 AM, jhaimerl <[email protected]> wrote:
Hi Vincent,
thanks for your reply. As there is nothing explicit defined on the roadmap, what do you think about a general interface for replacing the pdf renderering library? We defenetly will work internally on the PDF-Export and I think if we spend time on this, we could do it in a way the community could profit of. So what's your oppinion? How could the design be?
That would be cool :) The interface already exists, it's the Renderer interface. Basically you just need to implement a BlockRenderer and you're good. This will allow to generate PDF using your Renderer for any input syntax. This is what I started with https://github.com/xwiki/xwiki-rendering/tree/itext-pdf-renderer but using itext but you can implement it using anything. Thanks -Vincent
Thanks Josef
Hi Vincent, we now took a look at the following code and a few questions came up. First of all how should the renderer interface be embedded? What name do you suggest for the new component? Which injections and annotations are needed (e.g. what kind of information includes the @Named(…) annotation)? Are there any documents where we can read something about that? Where will be defined after which implementation class of the pdf library is searched in service of the injection? Maybe in the xwiki.cfg? In that context another question is where is defined which implementation of the class PrintRendererFactory will be injected? Will the currently used PDFExport interface be obsolete by that? Should the BlockRenderer interface either be implementated directly or has it to be inherited of the AbstractBlockRenderer class? Concerning the following code: We would suggest to insert a check in the export-method to determine if a custom pdf library is configured (e.g. in the xwiki.cfg) or not. If yes it'll be used, if not the standard export remains in force. -- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com.
Before answering your questions below I need to know what you mean by "custom PDF library". Thanks -Vincent On Jul 8, 2013, at 12:14 PM, jhaimerl <[email protected]> wrote:
Hi Vincent,
we now took a look at the following code and a few questions came up.
First of all how should the renderer interface be embedded? What name do you suggest for the new component? Which injections and annotations are needed (e.g. what kind of information includes the @Named(…) annotation)? Are there any documents where we can read something about that? Where will be defined after which implementation class of the pdf library is searched in service of the injection? Maybe in the xwiki.cfg? In that context another question is where is defined which implementation of the class PrintRendererFactory will be injected?
Will the currently used PDFExport interface be obsolete by that?
Should the BlockRenderer interface either be implementated directly or has it to be inherited of the AbstractBlockRenderer class?
Concerning the following code:
We would suggest to insert a check in the export-method to determine if a custom pdf library is configured (e.g. in the xwiki.cfg) or not. If yes it'll be used, if not the standard export remains in force.
Sorry this was a little misleading, I meant custom pdf export implementation, which uses any pdf rendering library for example iText. vmassol wrote
Before answering your questions below I need to know what you mean by "custom PDF library".
Thanks -Vincent
On Jul 8, 2013, at 12:14 PM, jhaimerl <
Josef.Haimerl@
> wrote:
Hi Vincent,
we now took a look at the following code and a few questions came up.
First of all how should the renderer interface be embedded? What name do you suggest for the new component? Which injections and annotations are needed (e.g. what kind of information includes the @Named(…) annotation)? Are there any documents where we can read something about that? Where will be defined after which implementation class of the pdf library is searched in service of the injection? Maybe in the xwiki.cfg? In that context another question is where is defined which implementation of the class PrintRendererFactory will be injected?
Will the currently used PDFExport interface be obsolete by that?
Should the BlockRenderer interface either be implementated directly or has it to be inherited of the AbstractBlockRenderer class?
Concerning the following code:
We would suggest to insert a check in the export-method to determine if a custom pdf library is configured (e.g. in the xwiki.cfg) or not. If yes it'll be used, if not the standard export remains in force.
_______________________________________________ users mailing list
users@
-- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com.
On Jul 8, 2013, at 2:03 PM, jhaimerl <[email protected]> wrote:
Sorry this was a little misleading, I meant custom pdf export implementation, which uses any pdf rendering library for example iText.
ok, good, iText is a good example but it works completely differently than FOP works. For FOP we use this workflow: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HCustomizi... For iText, it's completely different and you would build iText directly from the events (no need to generate HTML first, and apply various stylesheets). That's why in this case it would mean 2 completely different Renderers. Regarding hints, we could have as names: "fop/1.0" "itext/1.0" Thanks -Vincent PS: Note that using iText means shortcomings ATM, see http://jira.xwiki.org/browse/XRENDERING-147#
vmassol wrote
Before answering your questions below I need to know what you mean by "custom PDF library".
Thanks -Vincent
On Jul 8, 2013, at 12:14 PM, jhaimerl <
Josef.Haimerl@
> wrote:
Hi Vincent,
we now took a look at the following code and a few questions came up.
First of all how should the renderer interface be embedded? What name do you suggest for the new component? Which injections and annotations are needed (e.g. what kind of information includes the @Named(…) annotation)? Are there any documents where we can read something about that? Where will be defined after which implementation class of the pdf library is searched in service of the injection? Maybe in the xwiki.cfg? In that context another question is where is defined which implementation of the class PrintRendererFactory will be injected?
Will the currently used PDFExport interface be obsolete by that?
Should the BlockRenderer interface either be implementated directly or has it to be inherited of the AbstractBlockRenderer class?
Concerning the following code:
We would suggest to insert a check in the export-method to determine if a custom pdf library is configured (e.g. in the xwiki.cfg) or not. If yes it'll be used, if not the standard export remains in force.
_______________________________________________ users mailing list
users@
-- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com. _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Hi Vincent, we put down a design propsal for this one here http://dev.xwiki.org/xwiki/bin/view/Design/ExportActionadaptation <http://dev.xwiki.org/xwiki/bin/view/Design/ExportActionadaptation> . We would be happy if you take a look at it and tell us what you think. If you are happy, I'll will create a jira issue and start implementing. Thanks! Regards Josef vmassol wrote
On Jul 8, 2013, at 2:03 PM, jhaimerl <
Josef.Haimerl@
> wrote:
Sorry this was a little misleading, I meant custom pdf export implementation, which uses any pdf rendering library for example iText.
ok, good, iText is a good example but it works completely differently than FOP works. For FOP we use this workflow: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HCustomizi...
For iText, it's completely different and you would build iText directly from the events (no need to generate HTML first, and apply various stylesheets).
That's why in this case it would mean 2 completely different Renderers.
Regarding hints, we could have as names:
"fop/1.0" "itext/1.0"
Thanks -Vincent
PS: Note that using iText means shortcomings ATM, see http://jira.xwiki.org/browse/XRENDERING-147#
vmassol wrote
Before answering your questions below I need to know what you mean by "custom PDF library".
Thanks -Vincent
On Jul 8, 2013, at 12:14 PM, jhaimerl <
Josef.Haimerl@
> wrote:
Hi Vincent,
we now took a look at the following code and a few questions came up.
First of all how should the renderer interface be embedded? What name do you suggest for the new component? Which injections and annotations are needed (e.g. what kind of information includes the @Named(…) annotation)? Are there any documents where we can read something about that? Where will be defined after which implementation class of the pdf library is searched in service of the injection? Maybe in the xwiki.cfg? In that context another question is where is defined which implementation of the class PrintRendererFactory will be injected?
Will the currently used PDFExport interface be obsolete by that?
Should the BlockRenderer interface either be implementated directly or has it to be inherited of the AbstractBlockRenderer class?
Concerning the following code:
We would suggest to insert a check in the export-method to determine if a custom pdf library is configured (e.g. in the xwiki.cfg) or not. If yes it'll be used, if not the standard export remains in force.
_______________________________________________ users mailing list
users@
-- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com. _______________________________________________ users mailing list
users@
_______________________________________________ users mailing list
users@
-- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Vincent, have you already found time to think about the proposal? Regards, Josef jhaimerl wrote
Hi Vincent,
we put down a design propsal for this one here http://dev.xwiki.org/xwiki/bin/view/Design/ExportActionadaptation <http://dev.xwiki.org/xwiki/bin/view/Design/ExportActionadaptation> . We would be happy if you take a look at it and tell us what you think. If you are happy, I'll will create a jira issue and start implementing. Thanks!
Regards Josef vmassol wrote
On Jul 8, 2013, at 2:03 PM, jhaimerl <
Josef.Haimerl@
> wrote:
Sorry this was a little misleading, I meant custom pdf export implementation, which uses any pdf rendering library for example iText.
ok, good, iText is a good example but it works completely differently than FOP works. For FOP we use this workflow: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HCustomizi...
For iText, it's completely different and you would build iText directly from the events (no need to generate HTML first, and apply various stylesheets).
That's why in this case it would mean 2 completely different Renderers.
Regarding hints, we could have as names:
"fop/1.0" "itext/1.0"
Thanks -Vincent
PS: Note that using iText means shortcomings ATM, see http://jira.xwiki.org/browse/XRENDERING-147#
vmassol wrote
Before answering your questions below I need to know what you mean by "custom PDF library".
Thanks -Vincent
On Jul 8, 2013, at 12:14 PM, jhaimerl <
Josef.Haimerl@
> wrote:
Hi Vincent,
we now took a look at the following code and a few questions came up.
First of all how should the renderer interface be embedded? What name do you suggest for the new component? Which injections and annotations are needed (e.g. what kind of information includes the @Named(…) annotation)? Are there any documents where we can read something about that? Where will be defined after which implementation class of the pdf library is searched in service of the injection? Maybe in the xwiki.cfg? In that context another question is where is defined which implementation of the class PrintRendererFactory will be injected?
Will the currently used PDFExport interface be obsolete by that?
Should the BlockRenderer interface either be implementated directly or has it to be inherited of the AbstractBlockRenderer class?
Concerning the following code:
We would suggest to insert a check in the export-method to determine if a custom pdf library is configured (e.g. in the xwiki.cfg) or not. If yes it'll be used, if not the standard export remains in force.
_______________________________________________ users mailing list
users@
-- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com. _______________________________________________ users mailing list
users@
_______________________________________________ users mailing list
users@
-- View this message in context: http://xwiki.475771.n2.nabble.com/Using-a-commercial-pdf-rendering-library-t... Sent from the XWiki- Users mailing list archive at Nabble.com.
participants (2)
-
jhaimerl -
Vincent Massol