Menu
▾
▴
#319 Obsolete section in the README file
I mean "1.2 - USING DJVIEW4 AS A PLUGIN". Perhaps it coud be replaced by an explanation, why there is no djview4-based extension to the present day browsers. I am not aware of any explanation, although "Viewer Extension for Google Chrome" (https://www.cuminas.jp/en/products/google-chrome-extension) shows that this is at least theoretically possible,
BTW, my confusion which resulted in #318 was caused by an attempt to circumvent the problem by pasting into djview4 the URL provided by our server.
You're right.
README
man nsdejavu
To investigate: maybe your sever should not percent-escape the cgi argument question mark ?
Thanks for the suggestion, but the server is practically orphaned. After a routine system upgrade of the server our djview4poliqarp, which is also practically orphaned, stopped working, and pasting URLs to djview seems the only way.
I still don't understand why there is no DjVu viewer compatible with "Browser Extensions API" (I guess this is the correct name). Nobody needs it except me??? Would it be difficult to program? What qualification should the programmer have? How time-cosuming it can be? I can try looking for volunteers among Computer Science students, but need to know more about the task. I can also try to look for a grant which would be willing to pay for it, but again I need a cost estimation.
Or is there still a browser (for Linux at least) still supporting NSAPI?
Besides a couple specialty browsers, you can use the gnome browser
(gnome web, or epiphany-browser).
On 6/3/20 1:52 AM, Janusz wrote:
Related
Bugs:
#319Looks like at least on Debian there is quite a mess.
1. Although various sources claim gnome web is a default browser for Gnome, on a fresh install of Debian buster I had to install it by hand.
2. The djview-plugin package install iceweasel as a dependency. However when I start iceweasel I get just Firefox.
3. Last but not least, despite installing djview-plugin, epiphany-browser behaves just as Firefox, i.e. downloads the index file instead of opening it with djview.
I am using Ubuntu 18.04 here, and epiphany-browser works quite well with
nsdejavu (including indexed djvu documents).
I notice geometry issue with the <embed> tag, that I will try to solve.
On 6/3/20 10:12 AM, Janusz wrote:
Related
Bugs:
#319Try url "about:plugins" in epiphany to get the list of recognized plugins.
Sometimes the evince plugin that competes for djvu documents.
About modern web extensions. They're all javascript. We tried compiling
djvu to javascript but the performance is horrible.
On 6/3/20 8:23 PM, Leon Bottou wrote:
Related
Bugs:
#319On Thu, Jun 04 2020 at 0:23 +00, Leon Bottou wrote:
That's a good news but see below.
[...]
On Thu, Jun 04 2020 at 0:36 +00, Leon Bottou wrote:
I've created VBox virtual machines with Ubuntu 18.04 and 19.10. In both
of them the plugin is not recognized by epiphany-browser ("about:plugins"
produces an empty window, the index file is downloaded, not opened).
What do you suggest?
I have some additional questions, but I will return to them later.
JSB
See https://mail.gnome.org/archives/epiphany-list/2018-March/msg00002.html
This one is gone too...
On 6/4/20 5:15 AM, Janusz wrote:
Related
Bugs:
#319On Thu, Jun 04 2020 at 11:33 +00, Leon Bottou wrote:
Are you aware of any other?
[...]
Cuminas' DjVu Viewer Extension for Google Chrome is/was also Javascript? It
doesn't seems to work now but it's interesting as a possible proof of
feasibility.
Tools like https://webassembly.org/ are in any way relevant to the
problem?
Last but not least:
I don't care about opening a DjVu document in a browser windows. I want
to have it open in djview.
I think the problem can be solved in many ways. For example, a
javascript extension can put the address of the index file to the
clipboard and a simple extension to djview can make it open the document
taking the address directly from the clipboard.
A more sophisticated approach is an extension which starts a new
instance of djview with an appropriate address as the argument. Would
such extension be considered the brach of security by the present day
standards?
--
,
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien
The wikipedia page https://en.wikipedia.org/wiki/NPAPI has a list.
Also, in epiphany, the removal is very superficial. They no longer pass
the flag to webkit and they no longer do plenty of crufty things for
serving specific plugins such as the gnome-evince plugins. The most
likely to work is waterfox, which is basically a frozen firefox. I had
no success with konqueror5.
On 6/4/20 8:20 AM, Janusz S. Bień wrote:
On Thu, Jun 04 2020 at 12:33 +00, Leon Bottou wrote:
[...]
I've downloaded waterfox, but I'm confused how to configure it.
If you have success with it, please describe the procedure e.g. in
README.
You said "We tried compiling djvu to javascript but the performance is horrible." I vaguely remember the saying (probably from "Psychology of prograaming") that every working program is faster than a non-working one. I would like to add that it is also faster from a non-exiting one. I understand the preformance was unacceptable in comparison with the NSAPI plugin but perhaps it is sufficient to download an unbudled document, which now for many users is prohibitively difficult?
I was looking for the person who recompiled libdjvu with emscripten and found a new one: https://djvu.js.org/
This one is still a bit sluggish, but much better overall…
Leon
From: Janusz jsbien@users.sourceforge.net
Reply-To: "[djvu:bugs]" 319@bugs.djvu.p.re.sourceforge.net
Date: Tuesday, July 21, 2020 at 11:20 AM
To: "[djvu:bugs]" 319@bugs.djvu.p.re.sourceforge.net
Subject: [djvu:bugs] #319 Obsolete section in the README file
You said "We tried compiling djvu to javascript but the performance is horrible." I vaguely remember the saying (probably from "Psychology of prograaming") that every working program is faster than a non-working one. I would like to add that it is also faster from a non-exiting one. I understand the preformance was unacceptable in comparison with the NSAPI plugin but perhaps it is sufficient to download an unbudled document, which now for many users is prohibitively difficult?
[bugs:#319] Obsolete section in the README file
Status: closed
Group: djview
Created: Tue Jun 02, 2020 05:18 AM UTC by Janusz
Last Updated: Wed Jun 03, 2020 02:12 PM UTC
Owner: nobody
I mean "1.2 - USING DJVIEW4 AS A PLUGIN". Perhaps it coud be replaced by an explanation, why there is no djview4-based extension to the present day browsers. I am not aware of any explanation, although "Viewer Extension for Google Chrome" (https://www.cuminas.jp/en/products/google-chrome-extension) shows that this is at least theoretically possible,
BTW, my confusion which resulted in #318 was caused by an attempt to circumvent the problem by pasting into djview4 the URL provided by our server.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/djvu/bugs/319/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#319Thanks for the link! It's (yet?) unsuitable for our search engine (https://github.com/RussCoder/djvujs/issues/26) but it is a step forward. Still no easy way to download an ubundled documents like the dictionaries at https://djvu.szukajwslownikach.uw.edu.pl.
Last edit: Janusz 2020-07-22
Just a comment that SumatraPDF (using similar djvu code) had an old npapi browser plugin which was last time tested against "last known man standing" Waterfox CLASSIC" 64bit cross platform browser worked with djvu most recently tesed on windows in 2020.05 portable see https://forum.sumatrapdfreader.org/t/browser-npapi-plugin-current-suggestions/1370
https://www.waterfox.net/download/
for 32bit the last known contender was Seamonkey Version 2.49.5 from 2019 (~= Firefox 52 ESR)