20 Jan
2017
20 Jan
'17
3:14 p.m.
On Fri, Jan 20, 2017 at 2:10 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Anca,
On 18 Jan 2017, at 18:05, Anca Luca
<lucaa(a)xwiki.com> 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.
I'm not sure we fully understand eachother...
I printed to pdf with Firefox on Ubuntu the standard Sandbox.WebHome page
and none of the links we have in there are actually clickable, they are
plain text (in the Links section, with external links, or in the Table of
contents section, with internal links).
I don't understand exactly how XWikiServletURLFactory would help us control
links inside the pdf itself, if the pdf is generated by the client-side
software (it's true that html anchors seem to work for chrome, so that is
one way of doing it, but apparently not on firefox).
For the other points I would need to test more to see if they actually
answer what I am thinking of..
Anca
* 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 <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