Integrating PDF.js as PDF viewer in your web application

When writing business web applications you often need to show PDF files in your application. But this requires that the user has an installation of a PDF viewer (e.g. Adobe Reader) and the browser plugin is activated. With PDF.js there is a chance to provide reliable and consistent PDF viewing capabilities in your application. This post provides some background information and shows how to integrate the PDF.js viewer into your own application.

About PDF.js

PDF.js, mainly developed by Mozilla, provides a JavaScript library that makes it possible to render PDF files in a browser without using a browser plugin. This library does the rendering but isn’t responsible for providing any other functionality to the user like navigation, zoom levels or printing.

Additionally, there’s a complete viewer (implemented using html, CSS and JavaScript) that does the things mentioned above. A demonstration of this viewer is hosted on the project’s web page.

As PDF.js uses many technologies provided by modern browsers only, it doesn’t work with old browsers like Internet Explorer 8. For details on that you can refer to the project’s compatibility list.


PDF.js is licensed under the “Apache License, Version 2.0″ that makes it possible to use it in your own application.

Be aware that the PDF.js viewer also includes files of the Adobe CMap project. These files are available under the terms of a different license.


PDF.js is implemented in JavaScript and runs in a browser. This results in some limitations, so don’t expect every feature of PDF files to be supported or working correctly. But in my experience PDF files containing text and images only work very well.

Getting the PDF.js viewer

The README file of PDF.js describes how to build a version on your own.

You can also take a pre-built version from the “gh-pages” branch of the GitHub project (the branch can be downloaded as zip file). But be aware that this version isn’t minified and therefore not as efficient as possible. If using the version from the “gh-pages” branch, you’ll need to put the folders “web” (excluding the example PDF file) and “build” into your own web application. These are only static files that need to be downloaded by the browser, so no special server-side technology is needed.

Necessary adjustments

On the top of the file web/viewer.js you can adjust several settings. One setting is the default PDF file that is shown if no other file is specified. This is set by default to a value that is useful for the demo hosted on the project’s web page. You should change this to a reasonable value or about:blank to show nothing by default.

If you want the pdf.js and pdf.worker.js files to be in a different location than the build folder, you have to adjust two things:

The pdf.js file is included in the web/viewer.html file:

<script type="text/javascript" src="../build/pdf.js"></script>

The pdf.worker.js is included in the web/viewer.js file:

PDFJS.workerSrc = '../build/pdf.worker.js';

Showing PDF files using the PDF.js viewer

This is my favorite part as it is almost trivial… Simply open the web/viewer.html with a parameter file set to the URL of your PDF file. An example URL could look like this:

As you simply show an html file, you are free to embed the PDF.js viewer as IFrame, popup or opening it as new window/browser tab.

Some more thoughts

As current versions of Google Chrome and Mozilla Firefox already natively support showing PDF files, it could be unnecessary to force the usage of the self-hosted PDF.js viewer as this results in additional files to be downloaded. As the PDF viewer included in Firefox is based on the PDF.js viewer, the user potentially won’t even see the difference. So a valid option to provide best and efficient support for the users is to use the built-in PDF viewer of the browser if you are sure one is available and only use PDF.js for uncertain cases (e.g. users with Internet Explorer).

But it could also be desirable to use PDF.js on all browsers to ensure a consistent look and behaviour for all users.

If you need to support Internet Explorer 8, you should provide a fallback for those users. For example you could use an IFrame directly pointing at the PDF’s URL. If the user has a PDF viewer, it will be used. If not the file can be downloaded by the user as last fallback.

Posted in Web as a Platform | Tagged , , , , , , | Leave a comment

Resourcengebundene Ausführung auf Hazelcast Knoten durch Distributed Code Execution

Hazelcast stellt eine leicht zu bedienende API zur Verwaltung von verteilten Collections und Maps zur Verfügung. Die Verteilung der Daten auf die sich im Clusterverbund befindlichen Knoten ist für den Entwickler hierbei transparent.

Es hat sich gezeigt, dass ein Problem einer solchen verteilten Datenhaltung darin besteht, dass die Daten an den verarbeitenden Client übermittelt werden müssen. Bei großen Datenmengen stellt damit das Netzwerk einen Flaschenhals dar. Eine effektivere Methode als eine großen Menge Daten zum Code zu bringen, besteht darin, den Code dorthin zu bringen, wo die Daten vorliegen.

Desweiteren profitieren wir durch eine mögliche parallele Ausführung auf mehreren Knoten.

Eine weitere interessante Möglichkeit eröffnet sich allerdings auch, sollte ein auszuführender Code abhängig von zuvor angeforderten Ressourcen sein. Dies könnte zum Beispiel eine bestimmte Datenbankconnection, Transaktion oder allgemein eine Session sein, welche auf einem bestimmten Knoten in einem Cluster angefordert worden ist und dort gehalten wird.

Das In-Memory-Grid Hazelcast bietet hierfür umfangreiche Möglichkeiten, welche es erlauben, durch eine intuitiv zu bedienende API ohne größere Aufwände eine solche verteilte Ausführung umzusetzen.

Continue reading

Posted in Java Runtimes - VM, Appserver & Cloud | Tagged , , , , , | Leave a comment

Internet Explorer 11 will support source maps based debugging

The developer tools of Chrome and Firefox (as well as Firebug) used to support source map base JavaScript debugging for several versions. With the new update for Internet Explorer 11, all major browsers support this feature.

About source maps

Source maps provide a mapping of JavaScript code to other source code. This is very important whenever you use JavaScript code that is:

  1. Transpiled from another programming language (popular examples are GWT, TypeScript and Dart)
  2. Minified

As it is very hard (or almost impossible) to debug the resulting JavaScript code in the browser’s developer tools, source maps were introduced. With Source maps, the browser can execute the cryptic code, but the developer sees the original code while debugging.

Continue reading

Posted in Web as a Platform | Tagged , , , , , , | Leave a comment

TypeScript 1.0 Released – the statically typed super set of JavaScript

Microsoft announced the availability of the first stable release 1.0 of TypeScript – the statically typed super set of JavaScript.

Visual Studio 2013 Update 2 includes TypeScript 1.0 out of the box. Alternatively, there is also an add-on for Visual Studio 2012 and a Node.js package.
You can install the node.js package using the following command:

npm install -g typescript

Microsoft announced that they are now accepting contributions from the community. They will accept bug fixes and documentation improvements at the moment only, but in the future they will probably accept new features as well.

Until now, the community reaction on TypeScript was “wait until it’s ready”, at least as far as we have noticed. Now it is ready, and we will see if adoption increases both in community and enterprise.

Posted in Web as a Platform | Tagged , , , | 1 Comment

Upcoming GWT releases (2.7 and 3.0) in 2014 and beyond

According to Thomas Broyer, the plans for upcoming releases of GWT changed a little bit. In the comments of a Google+ post, he wrote the following:

The plan has shifted a bit. We’ll do a 2.7 near June, and will try to do a 3.0-alpha soon after that. And 3.0 will land at the end of the year (or early next year, like 2.6.0 this year).

So opposed to earlier plans, version 3.0 will not be the one after 2.6.x but there will be an additional version 2.7.

He also wrote about the currently planned features of the 2.7 release:

The goal for 2.7 is to have incremental compilation (that will tremendously speed up Super Dev Mode) and a beta of JsInterop (and remove support for IE6/7, and maybe deprecate support for IE8). And 3.0 will remove support for IE8.
Details are still being discussed.

As many people get nervous about Java 8 support in GWT, the following sounds very promising:

Java 8 seems to be in good shape for being supported in 2.7, at least at the language level. Emulation will require more work though (java.time!)

From my point of view this is very good news. We will get some of the new stuff early and don’t have to wait for a delayed 3.0 release. With a little bit of luck we can use Java 8 syntax (lambdas, method references, …) and the missing Java 8 API parts can probably be supported by additional libraries in the meantime until 3.0 is ready.

One last thing: About GWT 2.6.1, Thomas Broyer writes:

And yes, we’ll do a 2.6.1 very soon.

It seems that 2014 will be an exciting GWT year :)

Posted in Java Web Frameworks | Tagged , , , , | 1 Comment

MySQL Branch von Facebook, Google, LinkedIn und Twitter

Unter dem Motto

We’re Gonna Need A Bigger Database

arbeiten Entwickler von Facebook, Google, LinkedIn und Twitter an WebScaleSQL. Hier handelt es sich offiziell um ein Branch von der aktuellen MySQL 5.6. Eine entsprechende Meldung ist auf dem Entwicklerblog bei Facebook zu finden.

Man habe sich laut F.A.Q. für MySQL aufgrund der Roadmap für MySQL 5.7 entschieden. Die Änderungen werden mit der aktuellen MySQL Testsuite geprüft. Ziel des Teams ist es nicht,  noch eine Abspaltung von MySQL zu werden. Vielmehr bietet es allgemein interessante Änderungen an, die auch für andere Unternehmen mit entsprechendem Performance und Betrieb Bedarf  nützlich sein könnten. Es ist nicht ausgeschlossen, dass diese Änderungen auch in MySQL selber zukünftig aufgenommen werden.

Posted in Java Persistence | Tagged , | Leave a comment

GWT RPC deserialization vs IE8

Almost every web developer knows the nasty browser popup asking to cancel a long running JavaScript execution. In the case of Internet Explorer this message is “A script on this page is causing Internet Explorer to run slowly”.

This post will show what’s the specific behaviour of IE8, how this affects GWT RPC’s deserialization mechanism and how you can avoid these problems.

Continue reading

Posted in Java Web Frameworks | Tagged , , , , , , | Leave a comment