zathura-mupdf

[mullers]

Also, mir gefällt wie mupdf die pdfs rendert, nicht so gut gefällt es mir, wie zathura das macht. In allen anderen Belangen ist zathura mupdf überlegen, beispielsweise hat mupdf noch nicht einmal einen Druckdialog, und es erneuert sich nicht selbstständig bei der Nutzung von latexmk (könnte man einen wrapper dazwischen setzen, hab ich schon mal, will ich aber nicht)
So, es gibt dann eben auch zathura-mupdf, das die Seiten rendert wie mupdf (nicht via poppler), mit den ganzen zathura Vorteilen. Das müsste man sich selbst kompilieren, was ziemlich mühsam ist, da kommen noch einige Abhängigkeiten dazu (hab ich schon mal gemacht, will ich aber nicht)
Ich weiss nicht mehr genau, aber es könnte sein dass ich da mal über *.deb (zathura-mupdf) gestoßen bin; ich finde es aber nicht mehr (vielleicht täusche ich mich auch). Vielleicht weiss da jemand was...

[rendegast]

https://pwmt.org/projects/zathura-pdf-mupdf/
angegebene Abhängigkeit mupdf.

Reicht da nicht libmupdf-dev ?
Drin ist ein 10MB-ar-Archiv:

Code: Alles auswählen

# ll */usr/lib
libmupdf-dev_1.5-1+b2_amd64/usr/lib:
total 10004
-rw-r--r-- 1 root root 10242638 Oct 15  2014 libmupdf.a

libmupdf-dev_1.7a-1+b1_amd64/usr/lib:
total 10288
-rw-r--r-- 1 root root 10533904 Nov  2 00:30 libmupdf.a

(darin kompilierte *.o)

[mullers]

https://pwmt.org/projects/zathura-pdf-mupdf/
angegebene Abhängigkeit mupdf.

Reicht da nicht libmupdf-dev ?

Schön wärs. Allerdings, wie ich sehen konnte, gibt es da keine Extraverzeichnisse mit openjpeg und girara, die ich da mal zusätzlich kompilieren musste. Die Doku zum Bauen ist grottig und ignorant.
So, nachdem ich nach und nach einige devs installiert habe (ein Fallstrick: trotz installierter libcrypto-dev gibt es die Beschwerde, das libcrypto fehlt; muss libssl-dev installiert werden (was nirgends steht), ist jetzt hier Schluss:

Code: Alles auswählen

/usr/bin/ld: cannot find -lmujs

Sollte eigentlich in libmupdf-dev sein, soweit ich das verstehe, aber anscheinend doch nicht.

[CH777]

Code: Alles auswählen

/usr/bin/ld: cannot find -lmujs

Sollte eigentlich in libmupdf-dev sein, soweit ich das verstehe, aber anscheinend doch nicht.

Das wäre wahrscheinlich das hier.
Allerdings ist es m.E. kein gutes Zeichen, wenn die Entwickler nicht mal die Abhängigkeiten richtig auflisten können...

[mullers]

Code: Alles auswählen

/usr/bin/ld: cannot find -lmujs

Sollte eigentlich in libmupdf-dev sein, soweit ich das verstehe, aber anscheinend doch nicht.

Das wäre wahrscheinlich das hier.
Allerdings ist es m.E. kein gutes Zeichen, wenn die Entwickler nicht mal die Abhängigkeiten richtig auflisten können...

Aha, das ist ja eine richtige Überraschung. Dass es das nicht ins README geschafft hat? Na ja, fehlt ja sowieso fast alles. Wie auch immer, das ist dann auch nicht mehr die Zeit wert, die ich aufbringen soll; was weiss ich, was dann noch alles kommt; das beende ich dann hiermit.

[rendegast]

Es braucht von debian aus

• zathura-dev
  libmupdf-dev
  
  libjbig2dec0-dev
  libopenjp2-7-dev
  libjpeg62-turbo-dev
  (beim jpeg62 dem System entsprechend <-> turbo)

0.2.7 stößt dann auf schon genanntes '-lmujs'.
0.2.6 und 0.2.5 hängen an '-lmupdf-js-none'-

0.2.1 -0.2.4 hangen an muxps.h

0.2.0 geht nach einer Korrektur pdf.h

Code: Alles auswählen

#include <fitz.h>
#include <mupdf.h>

->

Code: Alles auswählen

#include <mupdf/pdf.h>

auf Compilerfehler.

0.2.8 und 0.2.9 werfen Compilerfehler.



Aussichtsreichster Kandidat scheint dann 0.2.7 zu sein.
Eventuell kann das '-lmujs' auf ein in debian vorhandenes 'js' resp. dessen dev-Paket umgebogen werden?
ZBsp. webkit/javascriptcore oder mozjs?

[mullers]

Habe den pwmt Entwicklern mal eine Mail geschickt. Antwort:

mujs is the javascript library of mupdf and should have been built during the mupdf built process.

`should' ist natürlich der Konjunktiv, da zumindest hat er Recht. Das ist natürlich großartig, dass ich das jetzt weiss, hilft mir aber nur am Rande.

[rendegast]

So steht es auch im changelog des libmupdf-dev_1.5

List of changes on master since MuPDF 1.3

* Headline changes:
* CMYK rendering (mudraw PWG and PAM formats)
* TIFF viewer (with multi-page support).
* Added MuJS Javascript interpreter.
* MuJS is the default, V8 and JavaScriptCore are compile time options.
* Javascript support has to be explicitly enabled with pdf_enable_js.
* All viewers now have JavaScript enabled in the default builds.
...

changelog.Debian:

mupdf (1.5-1) unstable; urgency=medium

* New upstream release. (Closes: #761960)
* Use git-buildpackage to maintain the package repository
* Unapply patches from source after build
* Use MUJS to provide JS functionality (Closes: #760480, #745247)
...

Ansonsten findet sich "mujs" leider nirgends im Paket,
insbesondere nicht in den *.o des Archivs libmupdf.a.





Im source der mupdf-Pakete befindet sich thirdparty/mujs/.
Es dürfte demnach wirklich in den Paketen eingebaut sein.
Also muß die Source von zathura-mupdf entsperchend modifiziert werden.
Es braucht dann wohl auch keine extra installierten dev-Pakete außer zathura-dev und libmupdf-dev,
da die kompilierten Bestandteile alle schon im libmupdf-dev stecken dürften.

[mullers]

Da es ja neben zathura-mupdf (dem zu bauenden plugin) nur noch einen weiteren vollwertigen pdf viewer gibt, der auf mupdf baut (mupdf selbst, als viewer, ist ja nicht vollwertig, ist auch nur als eine Art Vorzeigeprojekt gedacht), habe ich also mal mit dem anderen versucht - llpp.
Den nutze ich sowieso, allerdings aus einem unoffiziellen Repo, und der ist da schon etwas veraltet. Bei llpp aus git gibt es neben dem normalen build Skript auch ein buildall Skript, das zumindest die meisten Abhängigkeiten herbeizieht. Damit taucht dann auch mupdf im 3rd party Verzeichnis auf. Da scheitert der build Prozess aber auch, aufgrund verschiedener Fehler (es ist ziemlich absurd), aber letztlich auch an fitz.h (sollte eben auch im mupdf Verzeichnis sein, und ist es sogar auch).

Übrigens ergab ein kurzer Kontakt mit dem etwas unwilligen Entwickler (von zathura) im Kern nur etwas wie `Mutti, Mutti, ich bin unschuldig, F(r)itz hat Schuld.`