Dropping webkit

[nicoe]

This is just a suggestion not a bug at all. So you can do whatever you want with it ;).

But I was wondering if you ever though about dropping webkit in favor of something like weasyprint : https://github.com/Kozea/WeasyPrint

[sharoonthomas]

@nicoe been waiting for getting rid of the beast of webkit :)

I have never used WeasyPrint before. Will give this a try.

Have you used it before ?

[sharoonthomas]

@aroraumang any thoughts ?

[aroraumang]

@sharoonthomas Will give it a try ;)
Thanks @nicoe :)

[nicoe]

@sharoonthomas
Never tested it yet.

I just remember a presentation about it at pyconfr 2012 and the guy who wrote it was really impressive. It is definitively worth a try I think.

BTW, while looking at the different reporting solution in tryton I also noticed that GrasBauer are using pisa (or xhtml2pdf), I don't know what it's worth though …

[hiaselhans]

wow, that is indeed a very nice tool!
i ran some tests and it seems to be quite a bit faster + it respects much better the '@ page' css which seems to be partly broken in most html-engines...

if you like i can prepare a pull-request to support both...

( @nicoe something like an enum to choose the used rendering engine would be cool or not?)

☀️

[aroraumang]

@hiaselhans Sure, why not? ;)
I was also planning on working on it. I think support for both is nice. You can send a pull request anytime :)

[nicoe]

@hiaselhans
I think trytond will still provide only one reporting solution. But it should be easy to add additional solutions if the developer wants to use something else. Do we need an additional field, that could be used by developer implementing new kind or reporting engine, maybe. We have this kind of field in sale_invoice_grouping so that people can add their own method if they want.

[hiaselhans]

@aroraumang will prepare soon, as i find some time...

@nicoe thanks for your response, i am not to judge about the need neither, just asking you as i've seen the nice modularization youve already done in this topic...
the only thing that came to my mind is that developers (and other folks aswel) have their personal preference for creating reports, and a lot of possibilities to choose from..
thanks for the hint with sale_invoice_grouping_method, but i see it is of type ir.property which is on the roadmap for deletion? my first thought was just using an enum (selection) field which could be extended in '__ setup__' by "report-modules"

[nicoe]

• simon klemenc [2014-12-26 23:54 +0100]:

the only thing that came to my mind is that developers (and other
folks aswel) have their personal preference for creating reports, and
a lot of possibilities to choose from..
thanks for the hint with sale_invoice_grouping_method, but i see it
is of type ir.property which is on the roadmap for deletion?

Just to clarify: property fields will be replaced by function fields.
I was referring to sale_invoice_grouping_method because it demonstrates
that we already have this kind of concept (a selection field for which
tryton have currently only one value).

my first thought was just using an enum (selection) field which could
be extended in setup

That's my idea too.

[sharoonthomas]

@nicoe pr #25 is merged and there is weasy print support for reports that want to implement it. However, it would be nice to have this as a configuration option on reports which I think your new proposal for easily extending report engines build for version 3.5+

Creates issue #26 to handle the migration to new API for tryton 3.6