18 Jan
2017
18 Jan
'17
9:52 p.m.
On 01/18/2017 03:43 PM, Vincent Massol wrote:
It's not about selecting them manually from the browser, but specifying
it in the CSS. The CSS print module contains rules for this, but not all
browsers implement them.
"Better quality" is subjective... But with enough work on either side
(pdf.css or print.css) we can improve the look of the PDF. The main
problem is that nobody considered it a high enough priority to spend
time on making the PDF look nice. At a hackathon during 2012's XWiki
seminar, IIRC, there was some work for this, but I don't think that ever
got committed.
Long term, it does make sense to stop spending time on the FOP export
and into browser's print stylesheet.
On 18 Jan 2017, at 21:23, Sergiu Dumitriu
<sergiu(a)xwiki.org> wrote:
I think this is a good idea for the future, but not right now. There are
several things that current browsers don't support yet, such as the
ability to specify page size and orientation
I’ve just tested it and I could select the orientation, paper size, margins, whether
header/footers are printed, etc. , setting
custom headers and
footers, and we'd need to work more to generate the cover and ToC. With
FOP we can control exactly how things work in all browsers, while
leaving this part to the browser is guaranteed to lead to inconsistent
and buggy output.
Well that’s the problem and the reason why I sent this email: right now FOP doesn’t allow
us to control much because it’s limited and buggy. We have plenty of open jira issues
related to FOP and we’ve worked hard (too hard) to fix issues in the past and we’re stuck
on several of them (I can think of table auto layout).
When I’ve tried to export a wiki page both with the browser print button and with our PDF
export, I’ve had a better result (by better I mean that corresponds more to what the user
is viewing) with the browser print button. Of course our print.css is lacking a lot of
styles but that’s easily fixable (BTW I don’t understand why we don’t use view styles by
default, most of them should work just fine).
The other advantage is that browsers work all the time to improve this and thus we
delegate the work to them (we reduce our maintenance).
Note that I’m not suggesting to drop what we’re doing now but to not make it the default
since it’s of lower quality than the browser print result. What we could do right now is:
* Run some factual tests on various wiki pages and compare them with both solutions and
see which are best.
* Quickly try to improve our print.css to match our style.css more.
print.css shouldn't be an alternative to style.css, but something on top
of it, improving certain things for printing.
Thanks
-Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu
On 01/18/2017 08:54 AM, Vincent Massol 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
--
Sergiu Dumitriu
http://purl.org/net/sergiu