Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Vincent Massol]

> On 18 Jan 2017, at 21:42, Sergiu Dumitriu  wrote:
> 
> On 01/18/2017 12:05 PM, Anca Luca wrote:
>> 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)
> 
> There are commercial alternatives, but those are out of the question due
> to the license.
> 
> There's the programmatic PDF generation option with PDFBox, but that
> will require a MAJOR redesign of the export.
> 
> Then there's the option of building our own patched version of FOP with
> https://issues.apache.org/jira/browse/FOP-2469 included.

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.

> It wouldn't be
> the first time we use a patched library, and it seems to be the solution
> with the least amount of work needed.

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%20export%22%20AND%20project%20%3D%20XWIKI%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

We could take them one by one and see if using the print button would solve 
some of them.

Thanks
-Vincent

> -- 
> Sergiu Dumitriu
> http://purl.org/net/sergiu

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Sergiu Dumitriu]

On 01/18/2017 03:43 PM, Vincent Massol wrote:
> 
>> On 18 Jan 2017, at 21:23, Sergiu Dumitriu  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.

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.

>> , 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.

"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.

> 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
> 
>> 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
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Vincent Massol]

> On 18 Jan 2017, at 21:23, Sergiu Dumitriu  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.

Thanks
-Vincent

> 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

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Sergiu Dumitriu]

On 01/18/2017 12:05 PM, Anca Luca wrote:
> 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)

There are commercial alternatives, but those are out of the question due
to the license.

There's the programmatic PDF generation option with PDFBox, but that
will require a MAJOR redesign of the export.

Then there's the option of building our own patched version of FOP with
https://issues.apache.org/jira/browse/FOP-2469 included. It wouldn't be
the first time we use a patched library, and it seems to be the solution
with the least amount of work needed.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Sergiu Dumitriu]

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, 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.

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

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Anca Luca]

Interesting, however, I see at least 2-3 possible limitations:

* we will drop cover and table of contents
* browsers (operating systems?) that don't have print to pdf option, will
not have this working anymore
* 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)
* multipage pdf export (that we currently have in multiple forms) will have
to be re-thought
* 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)
* as resulting from the previous small test but easy to generalize: the
result of this feature will start to be browser dependent .

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  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

[xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Vincent Massol]

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

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Thomas Mortagne]

On Wed, Jan 18, 2017 at 7:10 AM, Marius Dumitru Florea
 wrote:
> On Tue, Jan 17, 2017 at 5:54 PM, Thomas Mortagne 
> wrote:
>
>> Hi devs,
>>
>> I'm thinking since a long time that maybe we should automatically make
>> superadmin the author of the pages when installing a XAR as long as
>> the current user (and current author) have programming right (i.e. has
>> the same rights than superadmin when the extension is installed). I
>> don't really see anything against it these days and it's easy to do so
>> why not.
>>
>>
>
>> Basically the goal is to reduce the possibility to break extensions
>> when you play with existing users/groups/rights. Common user case
>> being to get rid of some old adminsys leaving the company.
>>
>
> The solution you propose looks more like a hack or workaround for the the
> problem you mentioned. I'm +0 ATM.

The goal is not to discuss the way to fix this issue for good here.
I'm just proposing to do this easy change (which I don't agree is a
hack, you could argue that you expect the author of extension pages to
be some system user) which among other things make this use case a lot
less common.

>
> Thanks,
> Marius
>
>
>>
>> WDYT ?
>>
>> Note: to be complete we could imagine the same kind of thing for admin
>> user but that require the introduction of a virtual admin right user
>> like superadmin is a vitual programming right user. But let's not
>> discuss too many thing at once.
>>
>> --
>> Thomas Mortagne
>>



-- 
Thomas Mortagne