Interesting, however, I see at least 2-3 possible limitations: * we will drop cover and table of contents * browsers (operating systems?) that don't have print to pdf option, will not have this working anymore * 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) * multipage pdf export (that we currently have in multiple forms) will have to be re-thought * 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) * as resulting from the previous small test but easy to generalize: the result of this feature will start to be browser dependent .
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 <vinc...@massol.net> 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
