Customizing Adobe Reader: Display PDF in Browser

Melchior Joined: 29 May 2006 Posts: 29

Customizing Adobe Reader: „Display PDF in Browser“
“Missing Source“ nach Wahl von „Display PDF in Browser“ sowie Nichtfunktionieren dieser Checkbox unter einer Multilanguageumgebung (Versionen 7.x)

Ausgangslage
Acrobat Reader führt bei Wahl der unter dem Register „Internet“ befindlichen Checkbox „Display PDF in Browser“ (PDF in Browser anzeigen) ein/e Remove/ReInstallation eines Features aus. Ist die Originalsource nach Manipulation der Checkbox nicht mehr im ursprünglichen Ordner vorhanden, so wird eine Dialogbox zum Suchen der Source angezeigt!

Oftmals bestand die komplette Source aber nur zum Installationszeitpunkt im vorgegebenen Pfad. Dies kann bei einer Softwareverteilung innerhalb von Unternehmen in einem temporären Netzwerkverzeichnis sein oder aber auch in einem temporären lokalen Folder. Auch bei HomeUsers könnte diese Meldung erscheinen, wenn der Anwender nach der Installation von Adobe Reader dessen downgeloadete Source löscht.

Ein weiteres Problem entsteht, wenn wir verschiedene Sprachen von Adobe Reader gleichzeitig auf einem Client installieren. Adobe unterstützt zwar die parallele Installation verschiedensprachiger Readers und es gibt gar eine Option (International), wo nach einer Installation von mehreren sprachunterschiedlichen Readers zwischen den Sprachen gewechselt werden kann. Leider ist die Integration aber nicht durchgängig. Die Option „Display PDF in Browser“ funktioniert nach der Installation von mehr als einem Reader nicht mehr richtig!

Lösungsansatz:
Problem 1 – missing Source:
Der Zugriff auf die fehlende Source entsteht, bei Abwahl und erneuter Wahl der Checkbox. Dann wird nämlich eine zuvor deinstallierte Ressource benötigt. Windows Installer versucht das Feature „ReaderBrowserIntegration“ nachzuinstallieren. Dieses Feature beinhaltet einige Dateien, die zuvor durch die Abwahl der Checkbox auf dem lokalen Client gelöscht wurden.
(Für Deutsch beispielsweise AcroIEHelper.dll, AcroPDF.dll, AcroPDF.DEU, nppdf32.dll und nppdf32.DEU)

Eine Variante wäre, diese Dateien für immer in einem gecacheten Ordner zur Verfügung zu stellen, damit ein Zugriff auf die Originale MSI-Datei, bzw auch die dort verwiesene Cabinettdatei unnötig würde. Zu diesem Zweck ändert man in der Component-Table der originalen Adobe MSI-Datei zunächst den Zielpfad. In unserem Fall haben wir diesen von ACTIVE_X, bzw. BROWSER auf BROWSER_PATCH gesetzt.

Code:

Component                Directory_
ActiveX_AcroPDFdll.DEU    BROWSER_PATCH
ActiveX_AcroIEHelper.dll BROWSER_PATCH
ActiveX_AcroPDF.dll       BROWSER_PATCH
Browser_UI_German       BROWSER_PATCH
Browser             BROWSER_PATCH

Im Anschluss deklarieren wir diesen temporären Ordner über die Directory-Table…

Code:

Directory_ Directory-Parent DefaultDir
BROWSER_PATCH INSTALLDIR BrowserDuplicateFiles

…und geben in der Component-Table an, dass es diese Dateien in diesem gecacheten Verzeichnis bei einer Featuredeinstallation nicht deinstallieren soll, indem wir das Attribut-Flag auf 16 stellen (msidbComponentAttributesPermanent)

Jetzt haben wir diese Dateien zwar immer verfügbar, ab diese befänden sich an falscher Stelle in einem „falschen“ Verzeichnis. Damit nun bei einer entsprechenden Installation dieses Features diese Dateien trotzdem noch in den richtigen Zielordner gelangen, habe ich die entsprechenden Anweisungen über die Table „DuplicateFiles“ gesetzt. Zu diesem Zweck erstellt man eine neue Component mit leerem Inhalt (bspl. BrowserDummy) und weist diese Component dem Feature „ReaderBrowserIntegration“ zu.

Jetzt kann man über die Table „DuplicateFiles“ angeben, welche Datei wohin kopiert werden soll. (BrowserPatch1-5) Wichtig ist dabei die Spalte „Component_“. Hier deklariert man, wann diese Kopieroperation stattfinden soll. Nämlich dann, wenn die entsprechende Komponente installiert wird.

Code:

FileKey Component_ File_ DestFolder
BrowserPatch1 ActiveX_AcroPDF.dll AcroPDF.dll ACTIVE_X
BrowserPatch2 ActiveX_AcroIEHelper.dll AcroIEHelper.dll ACTIVE_X
BrowserPatch3 Browser nppdf32.dll BROWSER
BrowserPatch4 ActiveX_AcroPDF.dll_DEU AcroPDF.DEU ACTIVE_X
BrowserPatch5 Browser_UI_German nppdf32.DEU BROWSER

Jetzt haben wir einen funktionierenden Zustand um ein nicht geflagtes „Display PDF in Browser“ richtig setzen zu können. Was es uns noch nicht macht, ist diese Dateien zu löschen, wenn das Flag demarkiert wird. Zu diesem Zweck füllen wir die Table „RemoveFile“ ab. Wir setzen die Filenamen in Spalte „FileName“ (BrowserPatchRemove3-7) und das Zielverzeichnis unter „DirProperty“. Über die Spalte „Component_“ wird angegeben, wann der Remove ausgeführt werden soll. Nämlich immer dann, wenn unsere neu erstellte Komponente (BrowserDummy), welche zu dem Feature „ReaderBrowserIntegration“ gehört entfernt wird. Über die Spalte InstallMode definieren wir mit der Angabe „2“, dass der Remove, beim Remove der Componente stattfinden soll.

Code:

FileKey Component_ FileName DirProperty InstallMode
BrowserPatchRemove1 Reader_Bin_AcroRd32.exe *.* BROPWSER_PATCH 2
BrowserPatchRemove2 Reader_Bin_AcroRd32.exe BROPWSER_PATCH 2
BrowserPatchRemove3 BrowserDummy AcroIEHelper.dll ACTIVE_X 2
BrowserPatchRemove4 BrowserDummy AcroPDF.dll ACTIVE_X 2
BrowserPatchRemove5 BrowserDummy nppdf32.dll BROWSER 2
BrowserPatchRemove6 BrowserDummy nppdf32.DEU BROWSER 2
BrowserPatchRemove7 BrowserDummy AcroPDF.DEU ACTIVE_X 2

Jetzt zeigt sich auch, dass es nötig war, eine Pseudokomponente (BrowserDummy) zu erstellen. Hätten wir hier auf die originalen Komponenten (ActiveX_AcroPDF.dll, Browser, etc.) verwiesen, dann würde der Remove nie funktionieren, weil diese Komponenten durch uns in der Component-Table als „permanent“ geflagt wurden.

Über die Table „RemoveFile“ definieren wir auch das durch uns erstellte temporäre Verzeichnis ( BROWSER_PATCH - [INSTALLDIR]\BrowserDuplicateFiles), damit dieses bei einem Remove des Produktes wieder gelöscht wird (BrowserPatchRemove1-2). Da die darin befindlichen Dateien als „permanent“ gekennzeichet sind, würde ein regulärer Remove diese nicht entfernen.

Das so modifizierte Setup ist nun in der Lage, ohne Zugriff auf die Originalsource die Option „Display PDF in Browser“ zu setzen und wegzunehmen. Daneben wird das Produkt bei einer allfälligen DeInstallation auch wieder komplett vom System entfernt. Mit einer kleinen Ausnahme. Die an die Komponenten „ActiveX_AcroIEHelper.dll“ und „ActiveX_AcroPDF.dll“ gebundenen Registrykeys werden bei einer kompletten DeInstallation des Produktes sowie bei einer Feature-DeInstallation von „ReaderBrowserIntegration“ nicht mehr entfernt. Der Grund hierfür liegt auch wieder in der Tatsache, dass wir vorgängig für die Komponenten „ActiveX_AcroIEHelper.dll“ und „ActiveX_AcroPDF.dll“ das Attribut-Flag in der Component-Tabelle auf 16 gestellt hatten (msidbComponentAttributesPermanent).
Aus mir unerklärlichen Gründen funktioniert aber die BrowserIntegration nicht mehr durchgängig, wenn diese Key’s an das durch in diesem Verfahren erstellte Feature „BrowserDummy verknüft würden, was an sich die letzte noch offene Operation wäre. Daher habe ich auf diese Operation bewusst verzichtet.
Daneben verzichtete ich auch auf eine korrigierte Typelibregistration, in den ACTIVE_X-Pfad. Offenbar funktioniert auch alles Bestens, wenn die Registration auf „BrowserDuplicateFiles“ zeigt.

Problem 2 – Disfunktion bei Multilanguageumgebungen:
Um das zweite Problem in den Griff zu bekommen genügt es die vorgängig geschilderten Operationen für jedes Setup jeder Sprache durchzuführen. Wichtig ist dabei, dass man für jede Sprache eine neue Component-GUID für die BrowserDummy-Komponente erstellt. Nur dadurch ist gewährleistet, dass Windows Installer bei einem Remove des Features einer Sprache annimmt, dass es sich um eine einzelne Komponente handelt. Wären die Component-GUID’s gleich, so würde Windows Installer die Operationen aus der Table „RemoveFile“ nicht ausführen, da aufgrund eines Shared Zustandes, die Komponente in Tat und Wahrheit auch nicht entfernt würde.

Natürlich kann mit entsprechenden Tools aus diesen Änderungen eine Transformdatei erstellt werden, welche dann die Änderungen appliziert. InstallShield, Wise PackageStudio aber auch das Microsoft Platform SDK enthalten solche Tools, welche eine MST-Datei mittels Differenzabgleich bei Vorliegen zweier MSI’s vornehmen.

D. Oberlin

Piccolo Joined: 30 Aug 2007 Posts: 1

Hallo,

das gleiche Verhalten zeigt auch der AdobeReader in der Version 8.1.0.

Mit dieser Anleitung funktioniert es auch dort.

es grüsst der
Reto

Imperial Joined: 04 May 2007 Posts: 10

Hallo Dominik,

respekt, sehr gut durchdacht.

Wir verwenden ebenfalls den Adobe Reader 8.0 in verschiedenen Sprachen. Bei der Installation vom OS wird zuerst die US Version installiert. Danach kann sich jeder User über das Auftragsmanagement die entsprechenden Sprachen per SMS schicken lassen.

Die Installation läuft bei uns folgendermassen ab:
Die Sourcen werden erstmal über einen Wrapper lokal zwischengespeichert, nicht über SMS. Danach wird die Installation lokal ausgeführt. So weit, so gut

Ich habe jetzt mal probehalber die US Version 8.0 und die DE Version hintereinander getrennt von einem Reboot installiert.

Du schreibst:
Zitat: Ein weiteres Problem entsteht, wenn wir verschiedene Sprachen von Adobe Reader gleichzeitig auf einem Client installieren. Adobe unterstützt zwar die parallele Installation verschiedensprachiger Readers und es gibt gar eine Option (International), wo nach einer Installation von mehreren sprachunterschiedlichen Readers zwischen den Sprachen gewechselt werden kann. Leider ist die Integration aber nicht durchgängig. Die Option „Display PDF in Browser“ funktioniert nach der Installation von mehr als einem Reader nicht mehr richtig!

!!! Leider kann ich die Problematik, die du beschreibst nicht nachvollziehen !!!

Also ich kann Display PDF in Browser ab- und anwählen - zwischendurch die Sprache wechseln u.s.w.

Was soll denn da genau nicht funktionieren??

Über eine Antwort würde ich mich freuen.

Viele Grüsse,
Axel

Melchior Joined: 29 May 2006 Posts: 29

Hallo Axel
Tatsächlich geht die Wahl und Abwahl der Browserintegration bei der Benützung zweier Sprachen problemlos. Bei einer "International"-Version sind pro MSI immer zwei Sprachen implementiert, immer Englisch und eine weitere Sprache, beispielsweise Deutsch. Sollten weitere Sprachen eingesetzt werden, so verändert sich das Verhalten! Und dies ist auch bei der 8.1er Version noch so.
Zum einen wird die Einstellung nicht behalten, wenn die Sprache gewechselt wird (erkenntlich an der Checkbox), andererseits ist es dann oftmals gar nicht mehr möglich dass die Einstellung die richtige Auswirkung hat (Anschliessender Test der Browserintegrationn über IE schlägt fehl, bzw. macht nicht das gewünschte)
Die obigen Anpassungen sind notwendig, wenn keine lokale Zwischenspeicherung der Source erfolgt oder wenn man mehr als zwei Sprachen verwenden möchte (beispielsweise 4 sprachig für die Schweiz, dt., fr., it., en.).
Gruss

Dominik

Imperial Joined: 04 May 2007 Posts: 10

Hallo Dominik,

habe es gerade mal getestet. Es wurde EN, DE und FR installiert.

Bei uns werden wahlweise die Installationspakete lokal zwischengespeichert und von dort aus installiert. Also ist ein selfrepair kein Problem.

Eine Ab- und erneute Anwahl der option Display PDF in Browser ist ohne Fehlermeldungen möglich. Bei Ab- bzw. Anwahl wird jedesmal ein Repair durchgeführt und auf die original Source zugegriffen. So weit so gut.

Ich habe drei Dinge feststellen können, die unschön sind. Das vierte ist aber defintiv eine Fehlfunktion.

1.) Die Sprache im Explorer Kontext Menü ist immer die vom zuletzt installierten Paketes, nicht die aktuelle eingestellte Sprache. Auch nach einem Reboot ändert sich dies nicht.
Erst nach einem REINSTALL=ALL REINSTALLMODE=omus ändert sich das.

2.) Im Autostart Menü sind so viele Verknüpfungen zu Reader_SL.exe, wie Sprachen installiert sind. Das heisst 3 Sprachen, drei Mal reader_sl.exe im Taskmanager.

3.) Nach Abwahl von "Display PDF in Browser" einer Sprache und nachträglichem öffnen eines PDF'S im IE ist die Sprache des aktuelle Sprache des Readers.

4.) Selbst wenn bei allen Sprachen die Abwahl von "Display PDF in Browser" vorgenommen worden ist, zeigt der IE dennoch PDF's in seinem Fenster an, selbst nach einem Reboot.
Wie kann das, Das Feature wurde doch deinstalliert???

Hast du darauf eine Antwort?
Wenn ich die Pakete, wie du oben beschrieben hast modifiziere, behebt das unter 4.) beschrieben Problem?

Viele Grüsse,
Axel

Melchior Joined: 29 May 2006 Posts: 29

Zu 1.) das ist richtg. Ich verwende einen work-around gegen dieses Verhalten.
Zu 4.) Genau dies ist das eine Problem (eins von zwei). Dies wird mit einer Modifikation wie oben beschrieben behoben. Wenn Du interesse hast sende ich Dir gerne eine Transformation für Deutsch und eine für Französisch zu, welche diese Probleme behebt (mach mir doch über doctordeploy.com eine private message mit Deiner eMail-Adresse).
Gruss

Dominik