The patch in FOP-2469 is possibly not good enough which could explain why it’s not committed yet. So there might be more work to do before we could use it. Analysing and understand it is also quite some work I guess. There are 24 open issues with PDF export right now (and 10 bugs): http://jira.xwiki.org/issues/?jql=component%20%3D%20%22Old%20Core%20-%20PDF… We could take them one by one and see if using the print button would solve some of them. Thanks -Vincent

On Fri, Jan 20, 2017 at 2:10 PM, Vincent Massol <vincent(a)massol.net> wrote: 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

On Fri, Jan 20, 2017 at 2:10 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: Hi Anca, 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. 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. Windows <10 does not provide built-in print to PDF in IE Firefox for Windows/Linux needs an add-on to print to PDF These are just two examples, I am afraid you are optimistic about the availability of that feature. I am a Mac user like you, and I completely understand your point of view, but OS X is still the only OS fully integrating PDF support. Chrome browser has also a good deal of PDF support. But I am afraid we should also consider other situations. Maybe your proposal will be fine in a few years… but still I am sure to like it. I would like for the advantage in maintenance/development. But my current feeling is that our PDF generation server side is currently a differentiator for XWiki compared to competition. I am not sure, even if it was working smoothly that printing to PDF (which might just require a good CSS, not necessarily a custom page) really compare with downloading a server-side crafted PDF for end users. I am even convinced that a good PDF generation feature, with more easy customization, or even the ability to create Flipbooks would be a nice feature to have… However, I am no more confident that this would be easy to find. I have quickly made some research on currently available PDF libraries, and the conclusions are not matching my expectations. The most promising one was PDF Clown (http://www.stefanochizzolini.it/en/projects/clown/), which advertised a 2.0 version with what we really would like to have… but it had never been released and no commit since more than a year :( PDFBox which is a very mature PDF library is actually missing all the layout aspects, and experimentation made around it to convert HTML (see for example https://github.com/Jahia/html2pdf for example) does not look simple and so powerful. Wrapping wkhtmltopdf (which use Qt WebKit for rendering) is probably not a portable enough option, why not directly using LibreOffice to generate our PDF in that case. There is also pdfkit (http://pdfkit.org/) which is an emerging JavaScript library for generating PDF, but it is currently missing many layout aspect, just like PDFBox, and so not better. iText was already available when we choose FOP, it does not look like a better option today. So, even if this is not what I had expected, it seems that FOP is not that bad. Therefore, the proposal from Anca of applying the table patch might be an interesting option. We could also revamp the way we use FOP, in particular we might want to find better way to apply CSS to it, improve the validity of the generated XML and that way ensures better error reporting and recovery. So IMO, we should decide if we abandon our PDF feature or if we make some effort to make it right. I am +0 to make it right (not +1 simply because I will not have time for doing it even if I would like to see this happening). 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. Yes indeed. We would still be able to support this if we want by having our print.vm support it. 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. 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. Between improving the print feature and making the PDF better, I think that we might have a benefit doing just the opposite of what you propose, since having a good PDF implies having a good way to print. Of course, it implies that we do the improvement I mentioned above. So our preview could be the PDF export, and this would probably be nicer and more in line with what others do currently when it comes to printing. I have never been really happy with browser printing so far, it might improve, but today it is still really fragile. Thanks -Vincent Denis Gervalle SOFTEC sa - CEO

I’ve just tested it and I could select the orientation, paper size, margins, whether header/footers are printed, etc. 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. Thanks -Vincent

On 01/26/2017 05:59 AM, Anca Luca wrote: https://www.w3.org/TR/css-gcpm-3/#cross-references will do that, but no browser supports it yet. 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. 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 -- Sergiu Dumitriu http://purl.org/net/sergiu