Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

On Fri, Jan 20, 2017 at 2:10 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: Hi Anca, Actually we won’t. The idea would be to have to a Print button inside XWiki (right now we have Print Preview) and we would add support for cover + TOC in print.vm. I think all OSes support this. Do you have any meaningful OS/Browser in mind? We could still leave it as an option to use our PDF Export if users need it. Windows <10 does not provide built-in print to PDF in IE Firefox for Windows/Linux needs an add-on to print to PDF These are just two examples, I am afraid you are optimistic about the availability of that feature. I am a Mac user like you, and I completely understand your point of view, but OS X is still the only OS fully integrating PDF support. Chrome browser has also a good deal of PDF support. But I am afraid we should also consider other situations. Maybe your proposal will be fine in a few years… but still I am sure to like it. I would like for the advantage in maintenance/development. But my current feeling is that our PDF generation server side is currently a differentiator for XWiki compared to competition. I am not sure, even if it was working smoothly that printing to PDF (which might just require a good CSS, not necessarily a custom page) really compare with downloading a server-side crafted PDF for end users. I am even convinced that a good PDF generation feature, with more easy customization, or even the ability to create Flipbooks would be a nice feature to have… However, I am no more confident that this would be easy to find. I have quickly made some research on currently available PDF libraries, and the conclusions are not matching my expectations. The most promising one was PDF Clown (http://www.stefanochizzolini.it/en/projects/clown/), which advertised a 2.0 version with what we really would like to have… but it had never been released and no commit since more than a year :( PDFBox which is a very mature PDF library is actually missing all the layout aspects, and experimentation made around it to convert HTML (see for example https://github.com/Jahia/html2pdf for example) does not look simple and so powerful. Wrapping wkhtmltopdf (which use Qt WebKit for rendering) is probably not a portable enough option, why not directly using LibreOffice to generate our PDF in that case. There is also pdfkit (http://pdfkit.org/) which is an emerging JavaScript library for generating PDF, but it is currently missing many layout aspect, just like PDFBox, and so not better. iText was already available when we choose FOP, it does not look like a better option today. So, even if this is not what I had expected, it seems that FOP is not that bad. Therefore, the proposal from Anca of applying the table patch might be an interesting option. We could also revamp the way we use FOP, in particular we might want to find better way to apply CSS to it, improve the validity of the generated XML and that way ensures better error reporting and recovery. So IMO, we should decide if we abandon our PDF feature or if we make some effort to make it right. I am +0 to make it right (not +1 simply because I will not have time for doing it even if I would like to see this happening). Yes we can. This is controlled by the Browser which allows you to customise this. For the content of header/footer that’s easy, that would be the print.vm controlling them. Yes indeed. We would still be able to support this if we want by having our print.vm support it. Actually that should work better than what we have now ;) Note that we can do anything we want since we control the print.vm so we can use any XWikiServletURLFactory we want. So we control the layout completely. Then indeed it’s up to the browser to print. I don’t know if various browser print thing differently and how much difference there are between them. All I know is that they’ve spent way more men/hours than we’ve done on making a nice print ;) So again my goal in this proposal is to benefit from the Print feature of browsers, externalise the feature as much as possible (similar to what we’ve done with CKEditor). I wouldn’t want to drop our PDF export since it has some use cases, for example for generating export from scripts. I’m only referring to the basic Print option here and to transform the Print Preview into a Print one and tune it a bit to look as nice as possible. And make the Export to PDF optional and off by default. Between improving the print feature and making the PDF better, I think that we might have a benefit doing just the opposite of what you propose, since having a good PDF implies having a good way to print. Of course, it implies that we do the improvement I mentioned above. So our preview could be the PDF export, and this would probably be nicer and more in line with what others do currently when it comes to printing. I have never been really happy with browser printing so far, it might improve, but today it is still really fragile. Thanks -Vincent Denis Gervalle SOFTEC sa - CEO