Hi everyone,
Thanks to everyone who answered on this topic and help brainstorm about it. I
made a mistake sending this as a proposal; I should have sent it as a
brainstorming instead.
Note that I’ve also discussed with Anca yesterday and she told me that I
haven’t been nice in the way I answered her questions (not explaining enough
and throwing off her questions). I wanted to publicly apologise for this since
this wasn’t my intention and when reading my answers again I can see why this
was felt this way. Let me try to improve below :)
I also failed to explain properly the context that led me to send this email:
our roadmap for 9.0/9.1/9.2 had the table issue to fix (there was 2 days
allocated to it) and Guillaume worked on analysing it and the conclusion was
that it would take more than 2 days and would need to send some PR (or fork)
FOP and thus this issue is now dropped for 9.0/9.1/9.2. I was trying to think
out of the box and in order to provide a solution to Olivier Seres (who raised
the issue recently) I proposed to him that he used the browser’s print feature
and it did work better for this specific use case. So I thought to myself:
maybe there’s some value in using this more.
So let me try to recap what was said and reach a conclusion on this thread.
Features needed:
==============
* Table of contents. This is a difficult one. We can have a TOC generated in
our print.vm. The hard part is finding out the corresponding page numbers for
the use case when the user wants to print the PDF. It could maybe be solved by
setting fixed margins/paper size/orientation. But it doesn’t look easy. I
haven’t checked how it’s done in the PDF export though so I could be wrong.
* Page headers/footers. This is also a difficult one because even though this
is part of the css3-page spec, it’s not yet implemented by browsers and
especially by chrome. There are plenty of people trying to do this when I
googled it with various more or less successful options. A promising
possibility was the position:fixed option but it has its own issues (chrome
said they fixed the issue but not sure it’s true) and we’d need to make sure
that the text really goes in the margin and not in the content. It’s possible
that a combination of various solutions depending on the browser could work but
it’s not perfect and it’s complex.
* Margin sizes/orientation/paper size. This seems supported by the @page CSS
element and I saw it was mentioned to be supported by chrome but I didn’t get
to test it nor across browsers. To be tested.
* Local links. This should be ok I think since in the print.vm we can control
which XWikiServletURLFactory to use and generate anchors for local links. This
is essentially what we’re already doing for HTML export in the ExportURLFactory
class. However Anca raised the point that it doesn’t seem to work on FF. Would
need to be checked further.
* External links. I don’t think there’s any real issue here. I tried
PDF-printing a web page with links and it worked fine. I think the reason it
doesn’t work when doing this in xwiki could be because of our print.css which
removes the display of “a”:
#commentform, .xwikitabbar li, #Historyshortcut, #Informationshortcut,
.separator,
.commentheader .commenttools a, a.tag-delete , .tag-add a {
display: none !important;
}
* Browser-dependent result. True. In addition we’d need to ensure that browser
offer a print to PDF feature. I know this is true on Mac and also on FF in unix
(on Thomas’s computer and I think Thomas told me he didn’t have any add on).
Haven’t checked other combinations. Denis mentioned that it’s not the default
in Windows < 10.
Research
========
The following alternatives to FOP exist but have their own limitations (see
Denis answer for details):
* PDF Clown
* PDFBox
* wkhtmltopdf
* pdfkit
* iText
* Flying saucer, see
http://flyingsaucerproject.github.io/flyingsaucer/r8/guide/users-guide-R8.html#pdf
Conclusions
=========
I feel there are several main use cases:
* Wanting to print the current page. The browser print feature could work fine
for this if we were to improve a bit our print.css (inherit from view.css for
example)
* Wanting to have some professional quality PDF export. There’s no doubt that
the best solution for this is ATM our FOP-based PDF export and w
* Scripted PDF exports (to generate invoices automatically for example). Again
our FOP-based PDF export is the best answer.
So I agree with all of you who said that CSS3-page is not ready yet. The FOP2
spec has been stopped and the future seems to be CSS3-page but it’s not moving
fast right now.
So I propose that we:
* Marginally improve our print.css for page printing
* Continue to improve our FOP-based solution and possibly send PR to this
project and if they’re not applied quick-enough, then fork it and took some
ownership of it. However we just need to acknowledge that this is going to be
substantial work and we still have a sizeable number of open issue for the PDF
generation.
Thanks
-Vincent
> On 18 Jan 2017, at 14:54, Vincent Massol <[email protected]> wrote:
>
> Hi devs,
>
> We have plenty of existing limitations in our PDF export (table autoresize,
> etc) which comes from FOP and our usage of it. And it’s hard to improve it.
>
> I’d like to propose the following:
>
> * Promote the browser’s print to PDF feature instead of our PDF Export by
> triggering the browser’s print feature when clicking on Export > PDF in the
> UI.
> * Work on our print.css so that it has all the styles we have in view mode
> (right now for ex, info boxes for ex do not have a nice style).
> * Move our PDF Export java code out of xwiki-platform and into an optional
> extension that we move into xwiki-contrib. The use case for it would be when
> you need to generate PDF from scripts.
>
> WDYT?
>
> Thanks
> -Vincent
