Okular uses KHTML for the chm backend.

the chm backend uses khtml to convert the html to a bitmap.
QtWebengine doesn't have that capability.

QtWebengine can produce pdf's though, so that could be a route.

I don't think I have seen a chm file in a decade, so maybe just remove it?

Since we get bugs about it, people is using it, soo no let's not just remove it unless we can tell people, please use this other application that is actually supported

I think there was qchmviewer or something
May be worth trying seeing how good it is, if we can just point people there
Or if the UI is terrible we can try to steal the backend code (which is what we already did once i think)

there is a kchmviewer that uses qtwebengine directly for rendering. I don't know how that fits in the okular way of doing things.

there is a kchmviewer that uses qtwebengine directly for rendering. I don't know how that fits in the okular way of doing things.

Okular already uses the kchmviewer backend code, which supports two modes, QWebEngine and using KTHML. But switching to QWebEngine would break the current workflow used in okular, which is basically to render a page with khtml as a QImage and than return this QImage. AFAIK this is not possible with QWebEngine. So Okular would probably need a new Generator base class, to display HTML Documents using QWebEngine?

So Okular would probably need a new Generator base class, to display HTML Documents using QWebEngine?

You misunderstood the Okular API/codebase.

The only think Okular knows how to show is QImages.

There's no other thing that Okular can do that show images, everything is an image.

So if you want Okular to do something, it has to generate an image.

The only think Okular knows how to show is QImages.

Ahh ok, than I don't know, if porting is even possible, without putting tremendous effort into it. Or QWebEngine somehow gets the featurem to render QImages. But I doubt that, since it is using a completely different render framework.

Qt WebEngine renders web pages using Skia and is not using QPainter or Qt for this purpose. The HTML5 standard also now offers much better alternatives that were not available when native controls plugins were introduced in Qt WebKit.

https://doc.qt.io/qt-5/qtwebenginewidgets-qtwebkitportingguide.html

You can always QWebEnginePage::printToPdf and open the PDF depending how terribly slow that is

Potential solution, just drop CHM support https://tsdgeos.blogspot.com/2020/05/chmk-simple-chm-viewer.html

In T11539#231361, @aacid wrote:

Potential solution, just drop CHM support https://tsdgeos.blogspot.com/2020/05/chmk-simple-chm-viewer.html

If you plan to do something with it, then I guess around now would be a good time for being able to drop HTML from okular-20.12.

chmk Not happening for 20.12, maybe 21.04, and even if it doesn, i don't see a reason to drop chm support from okular until KF6-okular

Another potential solution is using litehtml/qlitehtml that seems to know how to paint to a qpainter and would solve the reason for which we can't move to qwebengine for example

As discussed in today's BoF: removing from KF6 board, not a blocker for KF6 itself.

Still relevant: https://invent.kde.org/graphics/okular/-/blob/047400294d4a0a8798d7045f0d6745c3f0b6eb8c/CMakeLists.txt#L268

A first approximation for a solution is to stop building the chm plugin at the KF6 port. I'm not sure if it will happen for the megarelease or not; there does not seem to be much progress.