So, how do we replace java?

[Matteo Steccolini]

Hello,

today another step has been made toward deprecationt of NPAPI: Chrome 42 is stable and it disables npapi plugins by default. That's fine, as I'm told that you can do anything you did with java with only web technologies nowadays.

Anyway, I'm a bit without a clue as to how to replace some specific functionality of an applet we are using in a cross-browser web application (supporting Internet Explorer 8-11, Chrome, Safari, Firefox).

1. Print. We need to print pdf documents silently (without preview) on a predefined printer (possibly a specific tray of a specific printer) with custom print options on non-standard paper. We are using PDFOne for the task. Is there some cross-browser web technology to do that?
2. Sign. We need to sign documents using a smartcard reader. We cannot choose to use something else as a signature system, because it's defined on national scale (Italy). Is there some cross-browser web technology to do that?
3. Generate pdf documents client-side. There is a part of our web applications that works in offline mode, so without accessing a server; this part needs to create pdf documents to later print them (with needs as in point 1). Is there a way to create pdf documents with javascript only?
4. Identify hostname (even through a proxy). We save configuration parameters associated to the host, not only the user, so we get the hostname with java. Is there a way in javascript to identify univocally a host without the user's intervention?
5. Accessing twain scanners. Our users scan (silently) documents that are immediately sent to a file server.

These are the main issues we need java for and haven't yet found an alternative solution to. Do such solutions exist?

Thank you.

Matteo Steccolini

[PhistucK]

You cannot do those with web technologies (well, technically, you can create a PDF using JavaScript, but unless such a library exists, it will take a lot of work).

But you can create a native application that will be installed manually and a Chrome extension that uses native messaging to communicate with the installed native application. Once you have a native application running, you can do whatever you want.

☆PhistucK

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[Christian Biesinger]

There's definitely JS PDF libraries, such as
http://mrrio.github.io/jsPDF/. Just found this in a quick Google
search, I'm sure there's more.

But yeah sounds like native messaging, or communicating via a local
HTTP server, is the way to go (that's how Austrian and German smart
cards handle their authentication)

-christian

[Matteo Steccolini]

That's an interesting library, somehow it didn't look that promising when we found it by the end of 2013, but it would be a good bet today. I don't know about performances on older hardware, but we already render upscaled html pages to canvas to images on those, so maybe they can do it.

The real deal breaker in this case is printing the rendered pdf afterwards, and I assure you that it took months of work to get the print margins right on every printer on every OS (with Java being a lot better and easier to work with than ActiveX).

So, if we went the road of native messaging the issue would be end of cross-browser status for our web application, or mantaining two (or more) versions of it. Or drop support for Chrome, waiting for some cross-browser technology to pop up before the end of support for java plugin in all the remaining browsers.

I don't have high hopes of Oracle doing something about the issue, unless a plugin api better than npapi is shared by all major browser developers.

Thank you for your suggestions.

Matteo

[Christian Biesinger]

It does sound that with your fairly specific constraints, you are not
in a good place. Of course for cross-browser support, you could reuse
most of the code for all of them and just write multiple relatively
small extensions for Firefox and Chrome (and IE?) to communicate with
the external code.

-christian