18 Jan
2017
18 Jan
'17
6:05 p.m.
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 <vincent(a)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