> On 26 Jan 2017, at 17:21, Sergiu Dumitriu <[email protected]> wrote: > > On 01/26/2017 05:59 AM, Anca Luca wrote: >> 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 <[email protected]> wrote: >> >>> 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). >> > > https://www.w3.org/TR/css-gcpm-3/#cross-references will do that, but no > browser supports it yet. > >>> >>> * 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
Ok then that seals it! The print to PDF is only for the print use case where links are not useful. The only discussion left now is the new one I posted about in the jira issue regarding flying saucer vs FOP: http://jira.xwiki.org/browse/XWIKI-5627?focusedCommentId=93983&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-93983 Thanks -Vincent > >>> #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 <[email protected]> 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
