Djvu documents support

[Zhiz0id]

Hello. There're a lot of djvu documents around.

Could you please implement support of this format or if you don't have time for this It'd be very helpful to have some some brief explanation how someone might be able to do it?

• http://djvu.sourceforge.net/

[pvuorela]

By my experience this is quite a marginal format compared to pdf and the common office app ones. For not spreading the resources too widely and thinly around we should keep some scope on the features we implement and so far I'm not convinced on doing this.

Having that said, the sources are here. Would need something compared to the PDF support via poppler we have now. Some external library that does the file reading and rendering to bitmaps, and here the integration to the UI.

[Thaodan]

Okular supports those and uses DjVuLibre: https://okular.kde.org/formats/ http://djvu.sourceforge.net/

[Zhiz0id]

Hello again. Thanks for the answers.

So I started this as a hobby project for fun and have some progress.

I made a repository which builds three packages

• https://github.com/Zhiz0id/djvulibre
  • libdjvulibre-devel
  • djvulibre-3.5.28-0
  • libdjvulibre21-3.5.28-0

Spec for the build taken from openSUSE and slightly tuned for SFOS. I tested it over latest SDK, looks good.

Is it possible to move this repository into https://github.com/sailfishos/ and include in the official repositories somehow? This is already useful because djvulibre package has several cli programms/utilities which might be helpful for users.

[pvuorela]

Hi,

Nice to hear you've been getting forward there fast. For Sailfish we aim to keep the distribution slim to lower the maintenance burden, so I think the inclusion would be more topical when there is, or about to be, something using the libraries.

[Zhiz0id]

Hey, hello again.

Made basic implementation. Looks quite promising. Please have a look.

• Pull request: https://github.com/sailfishos/sailfish-office/pull/189
• RPM packages: https://github.com/Zhiz0id/sailfish-office/releases/tag/1.4.0-djvu
• (slightly outdated version on this clip) https://www.youtube.com/watch?v=5__4y60BqIU

Features:

• information page
• plugin opens/renders djvu files
• zoom/rotation
• go to page

Heavely based on pdf plugin and ocular kdjvu wrapper (thanks for pointing out @Thaodan ) over libdjvu.

p.s. it looks like filebrowser on initial documents/file listing is closed or something, not able to use it.

[pvuorela]

I appreciate the effort here. However still not sure of aiming to merge because of the marginality of the format.

One way to get forward could be some separate app perhaps. The stuff here is open source so can be used on such. Regarding the harbour side the qtdocgallery isn't allowed but could get started by having some simpler file system based model.

Yea and the initial file list is exactly that qtdocgallery. It's all open, just not harbour approved.

[mentaljam]

Hi! I cannot agree that the format is marginal. Many educational materials (especially scanned old textbooks) are published as Djvu. Maybe it's typical for Russian-speaking countris. Howbeit, its support is something I miss in the office app.

[Zhiz0id]

Hello.

because of the marginality of the format

@pvuorela not sure that I understand your point.

DJVU is a popular and common format for documents. Format is in use on resources like wikisource.org and archive.org both of them have huge amount of djvu books. Also, as @mentaljam said the format is very popular for old scientific books and old books in general.

More resources:

• Wikisource:DjVu vs. PDF
• https://en.wikisource.org/wiki/Main_Page
• Example on wikisource: Shakespeare - First Folio Faithfully Reproduced, Methuen, 1910
• Example on archive.org: 2500 Years of Buddhism by Prof. P.Y. Bapat

One way to get forward could be some separate app perhaps.

There are several issues with a separate apps:

• This will require to impement file list for only one type of document files (which is kinda strange from user perspective).
• Sailfish OS has a default document viewer and from user perspective this is expected to be able to open as many documents as possible with this viewer (sailfish-office).
• Distribution of software on Sailfish OS has several drawbacks:
  • a lot of applications on Jolla Store are broken which breaks trust for users for the whole store.
  • application on a Jolla Store require support of every change in OS for this app and update the app everytime it suddenly breaks because of OS update (also to have a new environment every time OS updates just to be able to rebuild your project even if you don't care about development for a longer time), which most likely will kill the app someday (like it happened already with many).
  • openrepos.net is a third party apps directory, additional step to find an app for user means lose most of users (also there are many opened questions about trust, quality etc.)
  • chum - from user perspective very similar to openrepos.net, even the idea and environment is a very good, right now this solution is more like testing platform and hidden from most of a standard users.

Obviously all of those disadvantages are absent in sailfish-office. I understand that support of distribution and codebase require a lot of effort, but as I can see it in this case it is as low as possible:

• libdjvulibre is a very stable library, without any major changes for a long period and supported by original authors.
• djvu plugin for sailfish-office is in general separate because of nature of a project, so no any change to features which already implemented are made.

Compromise solution would be to have this plugin as a completely separate plugin package, but sailfish-office doesn't support this right now.

I'm interested to have it available as a part of the standard distribution and the default document viewer to give users additional but exptected feature for free, and hope Jolla will be also interested. If basic implementation will be merged, later I'll try to add more features like annotations and text search.

[nephros]

Compromise solution would be to have this plugin as a completely separate plugin package, but sailfish-office doesn't support this right now.

What would be required in order to enable sailfish-office to support third-party plugins?

[pvuorela]

I'm sure there can be some places where the format is more widely used but my experience is that generally these are quite rare. Like for every djvu document there's a thousand or more pdfs. That linked wikisource is offering downloads as epub, mobi and pdf. Djvu not even under the export behind "other formats". On some works it can be found as the original file, though.

On archive.org, quoting wikipedia: "In February 2016, the Internet Archive announced that DjVu would no longer be used for new uploads, among other reasons citing the format's declining use and the difficulty of maintaining their Java applet based viewer for the format." - https://en.wikipedia.org/wiki/DjVu

On generic support on the platform, looks like tracker-miners detects that the files are documents but has no other extractor for the metadata.

There are several issues with a separate apps: This will require to impement file list for only one type of document files (which is kinda strange from user perspective).

In a way, though PDF reader app wouldn't be understood as too strange because of that.

application on a Jolla Store require support of every change in OS for this app and update the app everytime it suddenly breaks because of OS update

Don't see why it would break more than any other random application. I.e. if it included its own code for reading and rendering the documents, implemented the file list by just reading the filesystem, it shouldn't need much other dependencies than just Silica for the UI.

What would be required in order to enable sailfish-office to support third-party plugins?

Well, on one hand the handling on different file formats is mostly just something mapping format to document page component on Main.qml and FileListPage.qml, which isn't too much. But then on the other hand I wouldn't like to commit making api stability promises for a plugin api or the current sailfish office qml plugin on ui components, and loading components into an app means it's trusting the code to be safe to be run in its context. So won't happen for harbour.

[Zhiz0id]

Hello again,

but my experience is that generally these are quite rare.

I hope decisions in Jolla are based not only on perception of one men but on some real data behind, otherwise we are losing our time in this discussion.

"In February 2016, the Internet Archive announced that DjVu would no longer be used for new uploads..."

But we're talking about reading/viewing files which already exist.

Like for every djvu document there's a thousand or more pdfs.

No validated data = not true

That linked wikisource is offering downloads as epub, mobi and pdf.

Not true. Those files are almost empty (only TOC?). Try to open these files from the example above:

• Mr. William Shakespeare's Comedies, Histories, and Tragedies Faithfully Reproduced in Facsimile from the Edition of 1623

In a way, though PDF reader app wouldn't be understood as too strange because of that.

On some popular platform this might be true, on Sailfish OS this is quite strange. When we are tight on resources much better to spend time to improve one app then create several weak apps.

I wouldn't like to commit making api stability promises for a plugin api

And we are talking about an app which doesn't change plugin logic for almost 10 years.

Anyway, thanks for sound your position.

[Zhiz0id]

Hello again!

On Aurora OS there is no such thing as sailfish-office, but djvu viewer is still very welcome. So I finally made a DjVu Viewer as a separate app. The same app ported to Sailfish OS and published in Jolla Store. Happy to say that the app finally approved today, so this piece of work is finally usable.

I'll close this issue and related PR as it looks like they're not needed anymore.

Thanks!