Presently in our web-application we used Java Applet as a PDF viewer, which also:
I recently heard that Google will end their Java Applet plugin support for Chrome.
Can I have the same limitations as mentioned above using a HTML5 based PDF viewer?
[...] blocks the user from saving the PDF document and prints the PDF content in physical printer (not in a soft printer i.e., save). [...] Can I accomplish above PDF viewer feature through HTML5 canvas?
The short answer to your question is, no, these features cannot be implemented using a HTML5 based PDF viewer.
Longer version:
If the PDF is loaded in the browser the document can also be download directly by the user as well. The browser and any solution it uses to display the PDF will have the same access level as the user, or put differently: the user has the same access level as the browser. The link is all that is required and can be easily obtained through the dev console (or a proxy).
Files cannot be loaded directly from a user's system. Due to security reasons, the user must pick the file so also here he already have access to the file in order to be able to pick it.
So downloading cannot be prevented.
Depending on the implementation of the viewer printing can be prevented if the viewer comply to this status flags of the document. There is no way to distinguish what type of printer is being used from inside the browser environment. JavaScript can only invoke a print dialog without knowing anything about the printer or the print process.
Even if it could: using a pure HTML5 solution means there will be JavaScript involved, in open source at the client. Part of the source code can be overridden by an user with programming skills. In any case, an user can simply screen-grab the page and save the grab.
So no, printing cannot be forced to a physical unit (or prevented).
For the browser, look at pdf.js. This is the solution Firefox is using and I believe Chrome will use in the future.