GNOME Bugzilla – Bug 168933
Have browser plugin
Last modified: 2015-08-25 12:04:48 UTC
When trying to use mozplugger 1.7.1 to enable, evince can be made to appear insidet he mozilla window, but it generates an error "unknown mime type". Depending on the moxplugger config, another window (or more) can be generated as well the last of which will actually be the file.
How is evince invoked by mozplugger? Arguments...
*** Bug 170365 has been marked as a duplicate of this bug. ***
Evince 0.1.9 now seems to work in Firefox with mozplugger 1.7.1 with the following line in mozpluggerrc: noisy swallow(evince) : evince "$file"
*** Bug 321097 has been marked as a duplicate of this bug. ***
*** Bug 142363 has been marked as a duplicate of this bug. ***
*** Bug 308254 has been marked as a duplicate of this bug. ***
*** Bug 336242 has been marked as a duplicate of this bug. ***
*** Bug 345880 has been marked as a duplicate of this bug. ***
Reopening to track the browser/Mozilla plugin (or did I miss a more recent bug?)
What was the outcome of WSOP?
I think that an official evince plugin for brosers could be nice. Thanks a lot
*** Bug 399946 has been marked as a duplicate of this bug. ***
Confirming bug, as it should be.
(In reply to comment #11) > I think that an official evince plugin for brosers could be nice. > > Thanks a lot > Just a feature request about the ability to pass parameters in the URL from an html link to the browser plugin in order to add functionalities such open a document at a specific page, chapter or anchor. Details of this whish is more described in this message of the gnome-list: http://mail.gnome.org/archives/gnome-list/2007-February/msg00041.html
*** Bug 440980 has been marked as a duplicate of this bug. ***
We aren't going to implement this. And evince work with mozplugger perfectly.
(In reply to comment #16) > We aren't going to implement this. And evince work with mozplugger perfectly. > What with webkit?
(In reply to comment #17) > What with webkit? Not going to change. Web browsers should open an Evince window instead of embedding it.
(In reply to comment #18) > (In reply to comment #17) > > What with webkit? > > Not going to change. Web browsers should open an Evince window instead of > embedding it. > Why? Why not let this options for users who find embedding more usable way of reading pdf files?
Would you accept a patch for a Mozilla plugin? This is something I've wanted to do for a long time, but I wouldn't want to waste my time.
> Why? Why not let this options for users who find embedding more usable way of reading pdf files Because it's hard to create a good UI inside a browser. It will be a completely different application and no code will be shared. So the decision is to support standalone documents. GNOME was going to embed everything everywhere but later this idea became unsupported mainly because of UI issues. > Would you accept a patch for a Mozilla plugin? no, thanks.
Hi, in fedora you only need to do this in order to have pdf files open in your browser window: yum install evince mozplugger reference url: http://www.fedorafaq.org/#pdf
(In reply to comment #18) > (In reply to comment #17) > > What with webkit? > > Not going to change. Web browsers should open an Evince window instead of > embedding it. This is simply not an option for some browsers. Sugar's Browse must either download the PDF or display it inline. We'd like to be able to display it inline, but since we're switching to webkit we can't use mozplugger. We'd have to do an ugly hack with evince. If there was a NPAPI plugin, everything would be easier and cleaner. The issue about UI in a browser would be moot, as this UI would be custom-made to work in a browser. Would you accept such a contribution?
IMHO no. The reason you put forward is bogus. What exactly would be the difference between the browser downloading the pdf and opening it in the pdf viewer (based on libevview, I suppose), and showing it in the browser in a 'custom-made' UI? There would be exactly zero difference, to the user. And since NPAPI is incredibly broken, from a developer standpoint, I'd go with the standalone app any time.
Then every browser that uses evince/poppler would have to implement yet another custom UI. I understand the concerns with NPAPI, but it's not exactly 'broken'. It works in virtually every browser. There is also Pepper, which will make things a lot better. For now, we're stuck with reimplementing pdf views in browsers, when most of us would be just fine with a generic NPAPI pdf viewer plugin. It's simply the wrong attitude for the developer of a pdf viewer to say "Web browsers should open an Evince window instead of embedding it.".
(In reply to comment #25) > Then every browser that uses evince/poppler would have to implement yet another > custom UI. 'every browser'? Sugar has more than one? (Or are you talking about the desktop?) Also, this is exactly backwards: NO browser needs to implement yet another custom UI, since when pdfs are handled externally, there needs only be ONE UI for it, namely Evince (desktop) or, on sugar, its pdf viewer (I suppose there is one, since you need to show local pdfs?) > I understand the concerns with NPAPI, but it's not exactly 'broken'. It works > in virtually every browser. Maybe if you've never tried writing a plugin; speaking as someone who HAS written NPAPI plugins, I maintain that it's broken. > There is also Pepper, which will make things a lot > better. For now, we're stuck with reimplementing pdf views in browsers, when > most of us would be just fine with a generic NPAPI pdf viewer plugin. There is absolutely no requirement to show pdfs in the browser; you can simply NOT implement it. > It's simply the wrong attitude for the developer of a pdf viewer to say "Web > browsers should open an Evince window instead of embedding it.". I disagree. It's exactly the right attitude to say that embedding pdfs in the browser is broken, should never be done, and therefore we won't ever support it.
(In reply to comment #26) > (In reply to comment #25) > > Then every browser that uses evince/poppler would have to implement yet another > > custom UI. > > 'every browser'? Sugar has more than one? (Or are you talking about the > desktop?) Every browser that uses gnome libs. At least Epiphany and Firefox come to mind. > Also, this is exactly backwards: NO browser needs to implement yet another > custom UI, since when pdfs are handled externally, there needs only be ONE UI > for it, namely Evince (desktop) or, on sugar, its pdf viewer (I suppose there > is one, since you need to show local pdfs?) Users want and expect inline PDF viewing. PDFs are just documents, like HTML and it's inconvenient and confusing to many users to keep switching between applications. They're especially terrified of the 'mess' they have to clean up afterwards, > > I understand the concerns with NPAPI, but it's not exactly 'broken'. It works > > in virtually every browser. > > Maybe if you've never tried writing a plugin; speaking as someone who HAS > written NPAPI plugins, I maintain that it's broken. I'll give you that, I've seen how painful it is. > > > There is also Pepper, which will make things a lot > > better. For now, we're stuck with reimplementing pdf views in browsers, when > > most of us would be just fine with a generic NPAPI pdf viewer plugin. > > There is absolutely no requirement to show pdfs in the browser; you can simply > NOT implement it. There is if your users require it. And they do if they work with a lot of PDFs. > > It's simply the wrong attitude for the developer of a pdf viewer to say "Web > > browsers should open an Evince window instead of embedding it.". > > I disagree. It's exactly the right attitude to say that embedding pdfs in the > browser is broken, should never be done, and therefore we won't ever support > it. Whether or not NPAPI is broken, I think you're about embedding PDFs in browsers in general, and so do users. Of course it's up to you to not support such a thing, but it makes things harder than they should be for browser devs.
(In reply to comment #27) > > 'every browser'? Sugar has more than one? (Or are you talking about the > > desktop?) > Every browser that uses gnome libs. At least Epiphany and Firefox come to mind. You started off saying you wanted this for sugar; so desktop browsers are irrelevant here. The evince developers have already, and repeatedly, rejected this request for the desktop. > Users want and expect inline PDF viewing. Esp. wrt. sugar, this is ridiculous. Sugar users are kids having no prior desktop computing experience; they don't 'expect' anything in this regard. > They're especially terrified of the 'mess' they have to clean up > afterwards, I fail to see how closing a pdf view is any different from closing a browser view? (Whether that's a window, a tab, ...) > Whether or not NPAPI is broken, I think you're about embedding PDFs in browsers > in general, and so do users. Of course it's up to you to not support such a > thing, but it makes things harder than they should be for browser devs. You think a browser plugin is important, while the evince developers think a browser plugin is a bad idea; that's ok, we disagree. However note there is nothing stopping you from developing a NPAPI browser plugin (whether using libevview, or poppler directly) yourself, in your own source code repository --- but the evince developers aren't going to do the work for you.
(In reply to comment #28) > You started off saying you wanted this for sugar; so desktop browsers are > irrelevant here. The evince developers have already, and repeatedly, rejected > this request for the desktop. On the grounds that they know better when it comes to browser UI design. > > Users want and expect inline PDF viewing. > Esp. wrt. sugar, this is ridiculous. Sugar users are kids having no prior > desktop computing experience; they don't 'expect' anything in this regard. Again you assume things about downstreams. Sugar users are not just kids, many teachers use it too. > > They're especially terrified of the 'mess' they have to clean up > > afterwards, > I fail to see how closing a pdf view is any different from closing a browser > view? (Whether that's a window, a tab, ...) It's about having extra files on disk, or in this case extra objects in the Journal. > > Whether or not NPAPI is broken, I think you're about embedding PDFs in browsers > > in general, and so do users. Of course it's up to you to not support such a > > thing, but it makes things harder than they should be for browser devs. > > You think a browser plugin is important, while the evince developers think a > browser plugin is a bad idea; that's ok, we disagree. However note there is > nothing stopping you from developing a NPAPI browser plugin (whether using > libevview, or poppler directly) yourself, in your own source code repository > --- but the evince developers aren't going to do the work for you. There have been offers of patches for evince, which were so vehemently refused. An effort supported by evince would have much better chance of survival. I don't mean to tell you what you to do (I apologise if it came out that way), I'm just pleading to you (evince devs) to reconsider and mentioning a use case you may have not thought of.
*** Bug 617562 has been marked as a duplicate of this bug. ***
Having the possibility to use evince in a browser would help spread the word about evince. It would help show evince to more people and hopefully get some donations. Ma company software can display PDF files inside a window of the program. This is done by some "magic" installed by Acrobat Reader (I don't if it's a plugin but this thread seems to imply this). As it's clear now that I won't be able to use evince for my customers, I'll have to stick to Acrobat reader. It means I'll have to install Acrobat on hundreds of computers. So it's the number of users that will never see evince.
(In reply to Philippe Ferrucci from comment #31) > Having the possibility to use evince in a browser would help spread the word > about evince. A browser plugin was added in GNOME 3.14, changing the resolution to reflect that.