
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>Hi,</p>

<p>Sorry for joining the discussion late.</p>

<p> </p>

<p>I agree that <span>QgsComposerLabel should be moved to QTextDocument.</span></p>

<p><span>For <span>QgsComposerHTML: </span>How about the proposal to package the revived QTWebkit (<a href="http://qtwebkit.blogspot.com.au/2016/08/qtwebkit-im-back.html">http://qtwebkit.blogspot.com.au/2016/08/qtwebkit-im-back.html</a>) along with QGIS, just as we are doing with other libraries? At least until QtWebEngine delivers the features we need?</span></p>

<p><span>It would also be less distribution dependent and probably save us a number of support headaches.</span></p>

<p><span>On the other hands there would be the additional packaging work.</span></p>

<p><span>Andreas</span></p>

<p>On 2016-09-14 08:17, Nyall Dawson wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Sooooo... now that we're close to cutting off Qt4 I guess it's time to<br /> start this conversation again. What should we do with web views in<br /> QGIS 3.0?<br /><br /> Here's the situation as I see it:<br /><br /> - upstream still hasn't made the new QtWebEngine classes anywhere near<br /> as featureful as the removed QWebView classes. I was hoping by the<br /> time we were ready for Qt5 this would have changed, but there hasn't<br /> been any really relevant changes since we last discussed this.<br /><br /> - the one minor expection to this is a new method which was added in<br /> Qt 5.7 - QtWebEngine::printToPdf [<a href="http://doc.qt.io/qt-5/qwebenginepage.html#printToPdf">1</a>] . The docs say:<br /><br /> "Renders the current content of the page into a PDF document and saves<br /> it in the location specified in filePath. The page size and<br /> orientation of the produced PDF document are taken from the values<br /> specified in pageLayout."<br /><br /> Potentially we could use this as a roundabout way of rendering web<br /> content offscreen - we could print the content out to a pdf, then<br /> somehow read it back in and render it to a QPainter surface. Maybe. I<br /> haven't been able to test this, but I have extreme doubts. Just<br /> looking at the docs I can't see anyway to control the DPI used for<br /> printing the content to a pdf, and my suspicion is that it will just<br /> be rendered using screen resolution.<br /><br /> Even with the long shot that we could successfully use this method<br /> it's still only available in Qt 5.7, which won't hit our target<br /> platform repos until mid 2029 ;)<br /><br /> - Possibly we could use the revived QtWebKit (see [<a href="http://qtwebkit.blogspot.com.au/2016/08/qtwebkit-im-back.html">2</a>]), but we'd<br /> probably need to package it ourselves. Advantages of this approach are<br /> numerous, including no loss of current features.<br /><br /><br /> Given all this... I think our realistic options are:<br /><br /> 1 Don't use a web engine. Use QTextDocument and it's limited html/css<br /> support. Disadvantages: we lose the ability to insert rich html<br /> including javascript, etc. Advantages: retain vector outputs and<br /> simple code.<br /><br /> 2 Render QtWebEngineView widgets as rasters in screen resolution.<br /> Disadvantages: pixelated, not vectorised and text converted to raster,<br /> requires use of a graphical widget which may cause issues with things<br /> like QGIS server (?). Advantages: can use javascript, videos, etc<br /><br /><br /><br /> My opinion:<br /><br /> QgsComposerLabel - approach 1. Switch to the basic QTextDocument support<br /><br /> HTML annotations - approach 2. These are likely used more often in the<br /> canvas interactively and the loss of resolution when they are used in<br /> composer is less important.<br /><br /> QgsComposerHTML - no idea. Probably option 2 but the loss of<br /> resolution/vector output will really hurt.<br /><br /><br /> It's probably time for us to address this, so we need to make a choice<br /> between these bad options. Any suggestions?<br /><br /> Nyall<br /><br /><br /> [1] <a href="http://doc.qt.io/qt-5/qwebenginepage.html#printToPdf">http://doc.qt.io/qt-5/qwebenginepage.html#printToPdf</a><br /> [2] <a href="http://qtwebkit.blogspot.com.au/2016/08/qtwebkit-im-back.html">http://qtwebkit.blogspot.com.au/2016/08/qtwebkit-im-back.html</a><br /> _______________________________________________<br /> Qgis-developer mailing list<br /><a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br /> List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br /> Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>

</blockquote>

<p> </p>

<div> </div>

</body></html>