Customizable Print Formats GSoC 2015

[Gehad Elrobey]

Thanks lubomir for your clarification.

When I tested rendering some svg images with QWebView it wasn't slow at
all. So the bottleneck in this process is saving QPicture as SVG?

Also we don't have to save the svg images to the disk and render them back
to QWebView, I found that we can access the QWebView requests directly by
extending QNetworkAccessManager class and overridding createRequest()
function, Then we can serve the meta:image/svg requests directly from
memory. do you think this will do any optimization?



On Sun, Mar 8, 2015 at 12:46 AM, Lubomir I. Ivanov <neolit123 at gmail.com>
wrote:

> On 8 March 2015 at 00:23, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
> >
> >
> > On Sun, Mar 8, 2015 at 12:11 AM, Lubomir I. Ivanov <neolit123 at gmail.com>
> > wrote:
> >>
> >> On 7 March 2015 at 23:47, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
> >> >
> >> > one thing to figure out is how are we going to embed the profile
> >> > pictures...
> >> > if we are capturing the output of a QWebPage then we first need to
> >> > show the profiles in there.
> >> > for that <img src="data: metatype, base64, theDataGoesHere" /> can be
> >> > used.
> >>
> >> now, there is an alternative for all that, but it's tricky...
> >> since we can use QWebFrame::render() on a QPainter that uses the
> >> QPrinter as paint device, in theory we can position a QPicture of the
> >> profile exactly over the already rendered profile HTML frame (e.g. in
> >> your PDF that would be "dive profile area"), but that's only in
> >> theory.
> >
> >
> > I was thinking of using Grantlee to generate parts of the HTML code, one
> > part for each widget that will be placed in the layout dynamically, we
> can
> > also insert the profile photos dynamically as the HTML code.
> >
> > So the Qt class will call Grantlee many times to fill in the <div> s (or
> > widgets in the main layout) dynamically and generate the full html code
> that
> > can be rendered by QWebPage and printed.
> >
>
> if i understand correctly you are planning to load the profiles as
> images in HTML and render both the dive data and the profile as a
> whole, via QWebPage. is that the case?
>
> but i think that for vector profiles in the printout to work, we need
> to use "meta:image/svg" instead of "meta:image/png" and that's why i
> proposed QSvg.
> we currently have the profile printed as vector (on Windows at least),
> so going back to strictly raster profiles in the printout is a step
> backwards.
>
> but if there is a way to avoid showing SVG in the HTML that would be
> the way to go, because it's going to be very slow.
>
> as i explained above, it will require some trickery (CSS?) to obtain
> the absolution position of where the profile has to be inserted on the
> page and it's dimensions.
> if we can estimate that, we can simply render a profile as QPicture
> over the HTML rendered layout (QPrinter being the paint device for
> both the underlying HTML template and the profiles which will be
> placed on top).
>
> lubomir
> --
>



-- 
regards,
Gehad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150308/0b51e477/attachment.html>