[packages]: include okular-backend-mupdf (_or_ poppler)

[jriddell]

luebking commented 7 days ago

Sidenote: you likely want https://github.com/xylosper/okular-backend-mupdf (originally written by Pino Toscano) because poppler performance sucks. Big time.

maybe we want to include this

[aleixpol]

Maybe it would be worth considering... In fact it doesn't look all that maintained.

[luebking]

No, doesn't (the okular plugin, MuPDF certainly is) - at least not strategically.

The major drawback of mupdf is printing (atm. you'd render into an image and print that), what makes it an inferior general purpose solution.

If that is however not a mandatory feature, it is much more performant (and battery conserving) than poppler - notably if the rendered page contains many or large images.

[hallarempt]

Weird, though -- poppler's performance was fine in the Harmattan days. We used it for the documents viewer back then: https://github.com/boudewijnrempt/office-tools, and later on for the Meego office document viewer. I'm not sure, but we might even have used poppler in the sailfish document viewer, but even though that's open source, I'm not sure where Jolla has put the repo. Maybe leinir knows?

[luebking]

poppler is ok at rendering simple text, it mostly stumbles on images (magazines) I was once pointed to http://eusoils.jrc.ec.europa.eu/projects/soil_atlas/download/Atlas.pdf as good testcase (starting from page 42)

So it's a matter of usecase, but if one considers e-magazines, one should consider avoiding poppler (and afaiu that's a systematic problem due to postscript invocation - not a bug that could be fixed "easily")

[star-buck]

IMG 128: we have 2xtimes an icon launcher for okular and 1x called "Document Reader"

[star-buck]

IMG 135: still I have 2x Okular icons on the desktop, and 1x non-working "Document Reader". Since "okular" does start, but hardly looks anywhere mobile-ready, we should remove it completely before akademy?

[notmart]

the installed okular mobile partly works, but i can manage to start it only from the command line: https://www.dropbox.com/s/r97tc3hp47075ai/VID_20150721_153510.mp4?dl=0

so at least the pdfs are correctly parsed and rendered. there are some problems in the qml layout, but most important some packaging/runtime issue connected with multiarch (and that's why "Document viewer" doesn't start from the app grid): in order to make it start i have to export LD_LIBRARY_PATH=/usr/lib/armhf/qt5/plugins in order for it to work, otherwise says that it cannot find the file "okularpart.so"

Also, the package should be split in order to make it possible to install only the mobile version and not the desktop one.

[notmart]

latest frameworks branch seems to have a problem in packaging http://mobile.kci.pangea.pub:8080/job/vivid_unstable_okular_bin_amd64/4/console

[hsitter]

Using mupdf seems to need an executive decision on whether we want poppler or mupdf, no?

[star-buck]

i'd vote for mupdf

[aleixpol]

I'd say it would be best to keep close to what we use in Okular desktop:

• more compatibility: forms, layers, annotations.
• If we improve it in one end, we'll leverage it on the other.
• It's supported by the Okular team.
• Poppler is proven, it was already used on the N9 and Ubuntu Phone.

[notmart]

also I'm using okular as a testbed for developing the common components used by applications, so that one should be used, regardless of the backend used. Also has QML components to be used in other applications, like the comicbook reader from bhushan. right now i've made pinch zoom faster, even tough loading of new pages (and actual resize after the zoom is over) can still be slow. so needs a bit of testing and eventually trying to build the mupdf backend in okular..

[star-buck]

okular works, so closing this for now here