On Fri, Jan 20, 2017 at 2:10 PM, Vincent Massol <[email protected]> wrote: Hi Anca,
> On 18 Jan 2017, at 18:05, Anca Luca <[email protected]> wrote: > > Interesting, however, I see at least 2-3 possible limitations: > > * we will drop cover and table of contents 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. > * browsers (operating systems?) that don't have print to pdf option, will > not have this working anymore 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). > * less customizations will be possible on this PDF (e.g. can we control > header / footer of the browser's print to PDF? Margins size, etc) 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. > * multipage pdf export (that we currently have in multiple forms) will have > to be re-thought Yes indeed. We would still be able to support this if we want by having our print.vm support it. > * will links continue to work properly as links inside the pdf ( I will > need to test - actually, I was talking about links that link to another > place in the PDF, but while testing I realized that my Firefox did not > export any link as link in pdf - internal or external - it only exported > text) 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. > * as resulting from the previous small test but easy to generalize: the > result of this feature will start to be browser dependent . 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 > For the problems of Apache FOP, does anyone have any idea what libraries do > other software use for this kind of functionality? (maybe there is a more > cool lib that we haven't found out about) > > Anca > > > On Wed, Jan 18, 2017 at 2:54 PM, 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 -- Denis Gervalle SOFTEC sa - CEO
