I'm trying to find a browser plugin or something like that to view/rotate/zoom/etc. multiple paged .tiff files. My requirements are that it must be cross-platform (Windows, Linux, ...) and cross-browser (Chrome, Firefox, IE, ...). The closest related topic I could find was this one, and almost everywhere points to AlternaTIFF, but it doesn't work in Linux.
Where can I find such plugin or is there anyway I can manipulate .tiff files via web browser?
Related
We have a Chrome extension that can be used to open a page into our website. From there the user then continues onto the next page which has a custom NPAPI plug-in embedded in it. This has always worked fine. However, since the version 32 update the plug-in loads and runs (it's a video conferencing plug-in and is clearly running as the other side can see video) however it doesn't show up on the page. Examining the DOM everything looks fine. Grabbing the border and re-sizing the browser will cause the plug-in to suddenly render correctly. I've tried all manner of javascript/css tricks to try and mimic this behavior as a workaround but nothing works. Tabs opened manually (not using chrome.tabs.create) work fine.
This worked up till 32.
Any ideas around this?
Chrome 32 is phasing out NPAPI, read the announcement here.
There is a deprecation guide that you can read here.
It seems like Google wants you to use it's Native Client tech to run native compiled code on user's machines. It is cool stuff...but so far I've found it difficult/more limiting to work with when compared to NPAPI (but there are obvious upsides, security for instance).
You could also build a native app and use native message passing to communicate from extension -> app. Once downside to this is that there is currently no way to bundle a native app into an extension install, so the user will need to download and install your app separately.
Our team uses Chrome Web Developer tools to debug JavaScript. As of yesterday when our browsers upgraded to Chrome Version 27.0.1453.93, the Sources section no longer lists all the JavaScript files. Does anyone know if this is a bug or if there is a setting? Some JavaScript files are still listed but I can't find the criteria for files being listed or not. I checked on an older Chrome Browser pointing to the same URL and all the files are listed. Anyone solved this?
I guess you may have some javascript code that has been loaded dynamically. If it is the case, you should use the phrase
//# sourceURL=foo.js
at the beginning of your javascript code. foo.js will be assigned it by debugger. And debugger will show it with that name.
chrome and firebug accept it, I am not sure about other browsers
There is a standard from Adobe that in theory specifies opening PDF documents from a link clicked in a browser in a way to open specific sections (AKA "anchor", "named reference") of PDF document. This functionality should be of great help if one would like to refer to a specific portion of large PDF (such as some standard or specification).
However, from what I see now, support for this standard is close to non-existent.
For example, these links should open Scala Reference PDF at section 3.2.6, "Annotated Types":
http://www.scala-lang.org/docu/files/ScalaReference.pdf#subsection.3.2.6
http://www.scala-lang.org/docu/files/ScalaReference.pdf#nameddest=subsection.3.2.6
http://www.scala-lang.org/docu/files/ScalaReference.pdf#page=23
(Techincally, variant #3 should open page #23, which is essentially the same destination)
Is there a working way (may be with a couple of shims, proprietary wrappers or whatever else) to make this work on majority of systems? What is the usage share of Adobe Reader plugin, should I care about other systems?
If it's not possible, at least I'd like to find a working solution for every platform (i.e. Windows, Linux, Mac) that I could recommend to my site's users if they want to be able to use named destination links.
From what I've tested:
Windows, MSIE/Firefox/Chrome, Adobe Acrobat Reader plugin - all variants work with version 9+, but:
MSIE has a weird caching issue (i.e. anchor does not work until document was cached)
Older versions do not work
It has issues with link format: generally, it should be regular absolute link to a real web server, starting with "http://". Relative links, samba-style links (\\HOST\dir\file.pdf#something), anything else besides "http" (or probably, "https") scheme won't work
Windows, any browsers set up to run Adobe Acrobat Reader as a separate process - does not work
Windows, any browsers, FoxIt Reader - does not work
Windows, any browsers, CutePDF - does not work
Linux/Konqueror/Okular - only variant #1 works
Linux, any other browsers set up to run Okular or any other PDF viewer as external process - does not work (as browser does not pass any "#arguments" in a command line)
Any OS, Firefox 15+ PDF.js internal PDF viewer - does not work
I'd appreciate if you'd try it to test in various different combinations.
What seems to work in general is variant #4 but using the number of the page as in actual division into pages in the PDF document, in this case
http://www.scala-lang.org/docu/files/ScalaReference.pdf#page=31
The PDF document has page numbers that start from the content proper, after the table of content, but that numbering differs from the one to be used in #page=...
I want to develop extensions for some main browsers like chrome and firefox. Extensions written using npapi can work in different browsers, however, there are very few browser extensions developed with npapi. Can you tell me the reasons? Thank you.
Your question confuses extensions and plugins; they are very different, and have completely different goals. You cannot develop an extension using NPAPI, only a plugin. You cannot write a single extension that works across browsers.
If you are asking why very few extensions include plugins, it's because plugins are much harder to write than extensions, are platform-specific, are not necessary for the vast majority of problems that extensions are trying to solve, are much more dangerous to users (since they have access to run arbitrary code on the machine), and aren't even allowed in extensions in some browsers (e.g., Safari).
If you didn't mean extensions at all, and are asking why there are few stand-alone NPAPI plugins, most of the list above still applies.
For all other browsers that I've tried in both Windows and MacOSX (including Chrome under Windows) using an "iframe shim" works fine. However, I have not been able to get iframe shims to work over our plugin in Chrome on the Mac.
Having Googled the problem, and done some testing, it appears to depend upon the object. I've found an example using StreetView (a flash object) which works, and another example using a Java Applet which does not work.
Some links:
Here's a description of the method: http://www.oratransplant.nl/2007/10/26/using-iframe-shim-to-partly-cover-a-java-applet/
This example using a Java Applet is from the above article: http://www.oratransplant.nl/files/iframe_shim.html
And here's the working version using Streetview: http://gmaps-samples.googlecode.com/svn/trunk/streetview/iframeshim.html
By inspecting (and editing) elements in Chrome and copying the objects between the two example pages, it appears to be that the flash object just allows iframe shims (in Chrome on the Mac), but that the Java Applet does not.
In our case we are using a custom plugin, built with Firebreath.
It may be that I need to implement extra functionality into our plugin, mimicking whatever flash is doing, but this could well be caused by a bug in the Mac build of Chrome.
Can anyone help? We really do want to be able to show HTML elements over our plugin, and the iframe shim works on almost all browser/OS combinations!
The lack of compositing is a known bug in Mac Chrome with any plugin using Core Animation or Invalidating Core Animation. It will be resolved in some future version--in theory, you should never need an iframe hack on the Mac, and plugins should always composite correctly. If you are interested, you can detect whether compositing of Core Animation is supported dynamically in your plugin using NPN_GetValue with the value 74656 (see WKNVSupportsCompositingCoreAnimationPluginsBool in the WebKit source; this should be added to the formal NPAPI spec soon, but the value won't change, so you can hard-code it now and when Chrome supports it that will start returning true).
In general the iframe hack should work in recent versions of Chrome (what version are you testing?), but there are some bugs where it doesn't get noticed until the page gets a re-layout, so you might want to play with forcing that.
Note that your Streetview example isn't a valid test on Mac Chrome, because it's using wmode=opaque, which means it's using the CG mode, not CA mode, and thus compositing works completely regardless of the iframe hack.
What drawing method are you using? You shouldn't need to use an iframe over a plugin on Mac because all drawing is windowless, unless you're doing strange things that I wouldn't expect to be possible with Chrome (i.e. creating an opengl context over a coregraphics or quickdraw context). If you were doing something like that there would probably not be anything you could do.
One easy setting would be to just resize the plugin to 1x1 to effectively "hide" it.