Customizable Print Formats GSoC 2015

[Lubomir I. Ivanov]

On 10 March 2015 at 17:49, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
> On Sun, Mar 8, 2015 at 9:40 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>> compared to what we do ATM - rendering the profile QWidget directly to
>> QPrinter which produces vector (Win32 / OSX only), the introduction of
>> SVG which is grabbed from a QWidget then displayed in QWebView which
>> is then rendered to QPrinter surely will slow things down as it
>> introduce an intermediate step (SVG).
>>
>> the alternative - somehow obtain the absolute position of the <div>
>> (jQuery?) where the profile should be located and it's scaled
>> dimensions on the page and then do QProfileWidget->render() at that
>> exact location on top of the already rendered HTML template. this
>> avoids SVG completely!
>>
>
> After I gave QWebView some tests I was able to render a QPicture on
> the top of the QWebView in the area of the dive profile. Getting the
> dive profile box location wasn't hard as I used
> QWebFrame::findAllElements() so I even didn't use javascript or
> JQuery.

awesome,

>
> Also by using our own rendering we will be able to provide printing
> with different qualities (DPIs) as an option, but we will lose some
> printing features that WebKit provides in its printing approach
> QWebFrame::print() ex. "@media print"  "page-break-inside"  so we will
> need to handle the pagination on our own.
>

again this is the solution i think is the correct one, to avoid SVG.
if we have way to much trouble with this second pass (layouting the
profiles on top of the pages), SVG is there as the backup plan.

> I attached a pdf printout of the QWebview rendering the HTML template
> and a QPicture rendered on top.
>

it seems to offset the profile QPicture a little vertically for each
page (moves it little above of the designated area), which could be a
rounding error. hopefully fixable by something like qRound() on our
side.

lubomir
--