26 Jan
2017
26 Jan
'17
5:21 p.m.
On 01/26/2017 05:59 AM, Anca Luca wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu
Hello Vincent, all
Thanks for these clear responses.
See below some more info, from my experience.
On Thu, Jan 26, 2017 at 11:15 AM, Vincent Massol <vincent(a)massol.net> wrote:
https://www.w3.org/TR/css-gcpm-3/#cross-references will do that, but no
browser supports it yet.
Hi everyone,
Thanks to everyone who answered on this topic and help brainstorm about
it. I made a mistake sending this as a proposal; I should have sent it as a
brainstorming instead.
Note that I’ve also discussed with Anca yesterday and she told me that I
haven’t been nice in the way I answered her questions (not explaining
enough and throwing off her questions). I wanted to publicly apologise for
this since this wasn’t my intention and when reading my answers again I can
see why this was felt this way. Let me try to improve below :)
I also failed to explain properly the context that led me to send this
email: our roadmap for 9.0/9.1/9.2 had the table issue to fix (there was 2
days allocated to it) and Guillaume worked on analysing it and the
conclusion was that it would take more than 2 days and would need to send
some PR (or fork) FOP and thus this issue is now dropped for 9.0/9.1/9.2. I
was trying to think out of the box and in order to provide a solution to
Olivier Seres (who raised the issue recently) I proposed to him that he
used the browser’s print feature and it did work better for this specific
use case. So I thought to myself: maybe there’s some value in using this
more.
So let me try to recap what was said and reach a conclusion on this thread.
Features needed:
==============
* Table of contents. This is a difficult one. We can have a TOC generated
in our print.vm. The hard part is finding out the corresponding page
numbers for the use case when the user wants to print the PDF. It could
maybe be solved by setting fixed margins/paper size/orientation. But it
doesn’t look easy. I haven’t checked how it’s done in the PDF export though
so I could be wrong.
As far as I remember, this is relying on an xsl-fo feature, the same one
that we use to obtain the number of printed pages (when we print
pagination, in footer, like 1/3, 2/3).
>
> * Page headers/footers. This is also a difficult one because even though
> this is part of the css3-page spec, it’s not yet implemented by browsers
> and especially by chrome. There are plenty of people trying to do this when
> I googled it with various more or less successful options. A promising
> possibility was the position:fixed option but it has its own issues (chrome
> said they fixed the issue but not sure it’s true) and we’d need to make
> sure that the text really goes in the margin and not in the content. It’s
> possible that a combination of various solutions depending on the browser
> could work but it’s not perfect and it’s complex.
>
> * Margin sizes/orientation/paper size. This seems supported by the @page
> CSS element and I saw it was mentioned to be supported by chrome but I
> didn’t get to test it nor across browsers. To be tested.
>
> * Local links. This should be ok I think since in the print.vm we can
> control which XWikiServletURLFactory to use and generate anchors for local
> links. This is essentially what we’re already doing for HTML export in the
> ExportURLFactory class. However Anca raised the point that it doesn’t seem
> to work on FF. Would need to be checked further.
No, what Anca said (and I can confirm) is that links don't work at all
in a PDF printed by Firefox/Linux. They aren't links, they're just
underlined plain text, unclickable. When printed from Chrome the URLs
work fine, and there's no need to use a special URLFactory, Chrome
correctly transforms relative URLs to absolute URLs.
Firefox most likely optimized its code for paper printing, with the
option to make an actual PDF that can be displayed on screen arriving
late, so it's a second class citizen, built on top of a process that
doesn't intend to generate an interactive document.
> * External links. I don’t think there’s any real
issue here. I tried
> PDF-printing a web page with links and it worked fine. I think the reason
> it doesn’t work when doing this in xwiki could be because of our print.css
> which removes the display of “a”:
No it doesn't, those are interactive JS-only tools that don't make sense
in a PDF. It's not hiding all <a> elements, just the following special
cases:
.commentheader .commenttools a
a.tag-delete
.tag-add a
#commentform,
.xwikitabbar li, #Historyshortcut, #Informationshortcut,
.separator,
.commentheader .commenttools a, a.tag-delete , .tag-add a {
display: none !important;
}
* Browser-dependent result. True. In addition we’d need to ensure that
browser offer a print to PDF feature. I know this is true on Mac and also
on FF in unix (on Thomas’s computer and I think Thomas told me he didn’t
have any add on). Haven’t checked other combinations. Denis mentioned that
it’s not the default in Windows < 10.
Research
========
The following alternatives to FOP exist but have their own limitations
(see Denis answer for details):
* PDF Clown
* PDFBox
* wkhtmltopdf
* pdfkit
* iText
* Flying saucer, see http://flyingsaucerproject.github.io/flyingsaucer/r8/
guide/users-guide-R8.html#pdf
Conclusions
=========
I feel there are several main use cases:
* Wanting to print the current page. The browser print feature could work
fine for this if we were to improve a bit our print.css (inherit from
view.css for example)
* Wanting to have some professional quality PDF export. There’s no doubt
that the best solution for this is ATM our FOP-based PDF export and w
* Scripted PDF exports (to generate invoices automatically for example).
Again our FOP-based PDF export is the best answer.
So I agree with all of you who said that CSS3-page is not ready yet. The
FOP2 spec has been stopped and the future seems to be CSS3-page but it’s
not moving fast right now.
So I propose that we:
* Marginally improve our print.css for page printing
* Continue to improve our FOP-based solution and possibly send PR to this
project and if they’re not applied quick-enough, then fork it and took some
ownership of it. However we just need to acknowledge that this is going to
be substantial work and we still have a sizeable number of open issue for
the PDF generation.
For tables layouting (XWIKI-5627), which seems to be our biggest problem
right now, i've seen implemented, in the past, some control the sizes of
the columns, but "manually" - as in, the size would not be computed
automatically depending on the content of the table. Set in a certain way
(I need to remember exactly how), the sizes of the columns can be imposed
to the pdf.
So, if table autolayout is such a pain (and there is serious proof to
support that it is), maybe we can offer a intermediate solution, such as a
"helper" for the user preparing the document: something like a macro or
even a wiki syntax snippet or something, that users could use to control
the sizes of the columns of a specific table. This would obviously not
cover all cases, but I think it could cover the usecase of Olivier Seres
(afaik the usecase is something like this: "he prepared a document for
print, he wanted to print it and realized that the tables were incorrect on
print". From my point of view, using this macro or snippet could be part of
the preparation of a document for print, and we could have it by default in
the wiki - if it's a macro - or as an FAQ if it's a snippet).
Lemme know if you're interested in this idea, as I will need to try to find
the code we used to do this.
Thanks,
Anca
>
> Thanks
> -Vincent
>
>> On 18 Jan 2017, at 14:54, 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
>
>