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. > > > * 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. > Could you please link me to some documentation (or element name or something) that would help me understand more precisely what technology we could use to achieve this? Thanks > > > * 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. > > 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 > >
