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