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