Gehört hatte ich schon öfters von dem Foxit Reader: Einem kleinen, schnellen Ersatz für den Adobe Acrobat Reader. Aber in einigen Applikation verwende ich den Acrobat Reader als Komponente zur PDF Darstellung. Das heißt der Acrobat Reader ist ohnehin notwendig auf meinem Rechner installiert. Auch selbst erzeugte PDFs sollen in erster Linie im Acrobat Reader funktionieren. Da hilft Foxit nicht viel.

Und so schlimm empfand ich das Original von Adobe dann auch nicht, dass der mentale Aufwand für einen weiteren PDF Reader gerechtfertigt war. Jetzt beschäftige ich mich bei einem aktuellen Projekt intensiver mit der Adobe Acrobat Linie und der zugehörigen SDK. Auf einmal benötige ich einen zusätzlichen PDF Reader. Wieso kann man nicht mit den Adobe Tools alleine die Aufgabe lösen?

Das Problem liegt in der Architektur von Adobe Acrobat Professional und dem Adobe Reader. Es ist vielleicht schon aufgefallen, dass wenn man einmal ein PDF mit einem der beiden geöffnet hat, das andere Tool nicht mehr funktioniert. War der Reader offen, geht kein Acrobat Professional mehr und umgekehrt. Klemmt irgendwie eine (scheinbare) Instanz der Tools, geht gar nichts mehr. Auch wenn mehrere Acrobat Fenster offen sind und eines einen modalen Dialog darstellt, geht im anderen Fenster nichts mehr.

Das fällt vielleicht normalerweise nicht auf, aber wer die SDK Dokumentation noch nicht auswendig kann, wird sich wundern: Man öffnet den JavaScript Editor in Acrobat und möchte seinen Code bearbeiten. Natürlich ließt man parallel die API Dokumentation. Nur was macht der arme Entwickler mit einer PDF Dokumentation, während er in einem PDF arbeitet? Gar nichts, zumindest nicht mit Adobe-Mitteln. Erst wenn man den Editor beendet, erwacht Acrobat wieder und die Dokumentation steht zur Verfügung. Nur wer vorher die richtige Seite in der SDK geöffnet hat, kann Code und Erklärung gleichzeitig studieren.

Die einfachste Lösung war für mich, den Foxit Reader für die Adobe Acrobat SDK zu verwenden. Ironie des großen Softwarehauses.