Zwischen Dateiformaten und PDF konvertieren converting-between-file-formatsand-pdf

Die Beispiele in diesem Dokument gelten nur für eine AEM Forms on JEE-Umgebung.

Über Generate PDF-Dienst

Der Generate PDF-Dienst konvertiert native Dateiformate in PDF. Er kann außerdem PDF-Dokumente in andere Dateiformate konvertieren und die Größe von PDF-Dokumenten optimieren.

Der Generate PDF-Dienst verwendet native Anwendungen, um die folgenden Dateiformate in PDF zu konvertieren.  Sofern nicht anders aufgeführt, werden nur die deutschen, französischen, englischen und japanischen Versionen dieser Anwendungen unterstützt.  Nur Windows bedeutet, dass nur Windows Server® 2003 und Windows Server 2008 unterstützt werden.

Der Generate PDF-Dienst konvertiert die folgenden standardbasierten Dateiformate in PDF.

Der Generate PDF-Dienst konvertiert PDF in die folgenden Dateiformate (nur Windows):

Für den Generate PDF-Dienst müssen Sie die folgenden Verwaltungsaufgaben ausführen:

Diese Aufgaben werden unter „Installieren und Bereitstellen von AEM Forms“ mithilfe von JBoss Turnkey beschrieben.

Mithilfe des Generate PDF-Dienstes können Sie diese Aufgaben ausführen:

Konvertieren von Word-Dokumenten in PDF-Dokumente converting-word-documents-to-pdf-documents

In diesem Abschnitt wird beschrieben, wie Sie mit der Generate PDF-API ein Microsoft Word-Dokument programmgesteuert in ein PDF-Dokument konvertieren können.

Zusammenfassung der Schritte summary-of-steps

So konvertieren Sie ein Microsoft Word-Dokument in ein PDF-Dokument:

Projektdateien einschließen

Schließen Sie die erforderlichen Dateien in Ihr Entwicklungsprojekt ein. Wenn Sie ein Client-Programm mit Java erstellen, schließen Sie die erforderlichen JAR-Dateien ein. Wenn Sie Webdienste verwenden, stellen Sie sicher, dass Sie die Proxy-Dateien einschließen.

Erstellen eines Generate PDF-Clients

Bevor Sie programmgesteuert einen Vorgang „Generate PDF“ durchführen können, müssen Sie einen Generate PDF-Service-Client erstellen. Wenn Sie die Java-API verwenden, erstellen Sie ein GeneratePdfServiceClient-Objekt. Wenn Sie die Web-Service-API verwenden, erstellen Sie ein GeneratePDFServiceService-Objekt.

Rufen Sie die in ein PDF-Dokument zu konvertierende Datei ab.

Rufen Sie das in ein PDF-Dokument zu konvertierende Microsoft Word-Dokument ab.

Konvertieren der Datei in ein PDF-Dokument

Nachdem Sie den Generate PDF-Service-Client erstellt haben, können Sie die createPDF2-Methode aufrufen. Diese Methode benötigt Informationen über das zu konvertierende Dokument, einschließlich der Dateierweiterung.

Abrufen der Ergebnisse

Nachdem die Datei in ein PDF-Dokument konvertiert worden ist, können Sie die Ergebnisse abrufen. Nachdem Sie beispielsweise eine Word-Datei in ein PDF-Dokument konvertiert haben, können Sie das PDF-Dokument abrufen und speichern.

Siehe auch

Konvertieren von Word-Dokumenten in PDF-Dokumente mithilfe der Java-API

Konvertieren von Word-Dokumenten in PDF-Dokumente mithilfe der Web-Service-API

Einbeziehung von AEM Forms Java-Bibliotheksdateien

Verbindungseigenschaften festlegen

Generieren der PDF-Service-API – Schnellstarts

Konvertieren von Word-Dokumenten in PDF-Dokumente mithilfe der Java-API convert-word-documents-to-pdf-documents-using-the-java-api

Konvertieren Sie ein Microsoft Word-Dokument mithilfe der Generate PDF- API (Java) in ein PDF-Dokument:

Siehe auch

Zusammenfassung der Schritte

Schnellstart (SOAP-Modus): Konvertieren eines Microsoft Word-Dokuments in ein PDF-Dokument mithilfe der Java-API

Einbeziehung von AEM Forms Java-Bibliotheksdateien

Verbindungseigenschaften festlegen

Konvertieren von Word-Dokumenten in PDF-Dokumente mithilfe der Web-Service-API convert-word-documents-to-pdf-documents-using-the-web-service-api

So konvertieren Sie ein Microsoft Word-Dokument mithilfe der Generate PDF-API (Web-Service) in ein PDF-Dokument:

Siehe auch

Zusammenfassung der Schritte

AEM Forms mithilfe von MTOM aufrufen

Aufrufen von AEM Forms mithilfe von SwaRef

Konvertieren von HTML-Dokumenten in PDF-Dokumente converting-html-documents-to-pdf-documents

In diesem Abschnitt wird beschrieben, wie Sie mit Generate PDF-API HTML-Dokumente programmgesteuert in PDF-Dokumente konvertieren können.

Zusammenfassung der Schritte summary_of_steps-1

Führen Sie die folgenden Schritte aus, um ein HTML-Dokument in ein PDF-Dokument zu konvertieren:

Projektdateien einschließen

Schließen Sie die erforderlichen Dateien in Ihr Entwicklungsprojekt ein. Wenn Sie ein Client-Programm mit Java erstellen, schließen Sie die erforderlichen JAR-Dateien ein. Wenn Sie Webdienste verwenden, stellen Sie sicher, dass Sie die Proxy-Dateien einschließen.

Erstellen eines Generate PDF Client

Bevor Sie programmgesteuert einen Generate PDF-Vorgang durchführen können, müssen Sie einen Generate PDF-Dienstclient erstellen. Wenn Sie die Java-API verwenden, erstellen Sie ein GeneratePdfServiceClient-Objekt. Wenn Sie die Webdienst-API verwenden, erstellen Sie einen GeneratePDFServiceService.

Abrufen des HTML-Inhalts zum Konvertieren in ein PDF-Dokument

Verweisen Sie auf HTML-Inhalte, die Sie in ein PDF-Dokument konvertieren möchten. Sie können auf HTML-Inhalte wie eine HTML-Datei oder HTML-Inhalte verweisen, die über eine URL zugänglich sind.

Konvertieren des HTML-Inhalts in ein PDF-Dokument

Nachdem Sie den Dienst-Client erstellt haben, können Sie den entsprechenden PDF-Erstellungsvorgang aufrufen. Dieser Vorgang benötigt Informationen über das zu konvertierende Dokument, einschließlich des Pfads zum Zieldokument.

Ergebnisse abrufen

Nachdem der HTML-Inhalt in ein PDF-Dokument konvertiert wurde, können Sie die Ergebnisse abrufen und das PDF-Dokument speichern.

Siehe auch

Konvertieren von HTML-Inhalten in ein PDF-Dokument mithilfe der Java-API

Konvertieren von HTML-Inhalten in ein PDF-Dokument mithilfe der Webdienst-API

Einbeziehung von AEM Forms Java-Bibliotheksdateien

Verbindungseigenschaften festlegen

Generate PDF Service-API Schnellstarts

Konvertieren von HTML-Inhalten in ein PDF-Dokument mithilfe der Java-API convert-html-content-to-a-pdf-document-using-the-java-api

Konvertieren Sie ein HTML-Dokument mithilfe der Generate PDF-API (Java) in ein PDF-Dokument:

Siehe auch

Konvertieren von HTML-Dokumenten in PDF-Dokumente

Schnellstart (SOAP-Modus): Konvertieren von HTML-Inhalten in ein PDF-Dokument mithilfe der Java-API

Schnellstart (SOAP-Modus): Konvertieren von HTML-Inhalten in ein PDF-Dokument mithilfe der Java-API

Einbeziehung von AEM Forms Java-Bibliotheksdateien

Verbindungseigenschaften festlegen

Konvertieren von HTML-Inhalten in ein PDF-Dokument mithilfe der Webdienst-API convert-html-content-to-a-pdf-document-using-the-web-service-api

So konvertieren Sie HTML-Inhalte mithilfe der Generate PDF-API (Webservice) in ein PDF-Dokument:

Siehe auch

Konvertieren von HTML-Dokumenten in PDF-Dokumente

AEM Forms mithilfe von MTOM aufrufen

Aufrufen von AEM Forms mithilfe von SwaRef

Konvertieren von PDF-Dokumenten in Nicht-Bildformate converting-pdf-documents-to-non-image-formats

In diesem Abschnitt wird beschrieben, wie Sie mit der Generate PDF-Java-API und der Webservice-API ein PDF-Dokument programmgesteuert in eine RTF-Datei konvertieren können. Dies ist ein Beispiel für ein Nicht-Bildformat. Andere Nicht-Bildformate sind HTML, Text, DOC und EPS. Stellen Sie beim Konvertieren eines PDF-Dokuments in RTF sicher, dass das PDF-Dokument keine Formularelemente wie eine Senden-Schaltfläche enthält. Formularelemente werden nicht konvertiert.

Zusammenfassung der Schritte summary_of_steps-2

Führen Sie die folgenden Schritte aus, um ein PDF-Dokument in einen der unterstützten Typen zu konvertieren:

Einschließen von Projektdateien

Schließen Sie die erforderlichen Dateien in Ihr Entwicklungsprojekt ein. Wenn Sie ein Client-Programm mit Java erstellen, schließen Sie die erforderlichen JAR-Dateien ein. Wenn Sie Webdienste verwenden, stellen Sie sicher, dass Sie die Proxy-Dateien einschließen.

Erstellen eines Generate PDF Client

Bevor Sie programmgesteuert einen Generate PDF-Vorgang durchführen können, müssen Sie einen Generate PDF-Dienstclient erstellen. Wenn Sie die Java-API verwenden, erstellen Sie ein GeneratePdfServiceClient-Objekt. Wenn Sie die Webservice-API verwenden, erstellen Sie ein GeneratePDFServiceService-Objekt.

Abrufen des zu konvertierenden PDF-Dokuments

Rufen Sie das PDF-Dokument ab, das in ein Nicht-Bildformat konvertiert werden soll.

Konvertieren des PDF-Dokuments

Nachdem Sie den Service-Client erstellt haben, können Sie den PDF-Exportvorgang aufrufen. Dieser Vorgang benötigt Informationen über das zu konvertierende Dokument, einschließlich des Pfads zum Zieldokument.

Speichern der konvertierten Datei

Speichern Sie die konvertierte Datei. Wenn Sie beispielsweise ein PDF-Dokument in eine RTF-Datei konvertieren, speichern Sie das konvertierte Dokument in eine RTF-Datei.

Siehe auch

Konvertieren eines PDF-Dokuments in eine RTF-Datei mithilfe der Java-API

Konvertieren eines PDF-Dokuments in eine RTF-Datei mithilfe der Webservice-API

Einbeziehung von AEM Forms Java-Bibliotheksdateien

Verbindungseigenschaften festlegen

Generate PDF Service-API Schnellstarts

Konvertieren eines PDF-Dokuments in eine RTF-Datei mithilfe der Java-API convert-a-pdf-document-to-a-rtf-file-using-the-java-api

So konvertieren Sie ein PDF-Dokument mithilfe der Generate PDF-API (Java) in eine RTF-Datei:

Siehe auch

Zusammenfassung der Schritte

Schnellstart (SOAP-Modus): Konvertieren von HTML-Inhalten in ein PDF-Dokument mithilfe der Java-API

Einbeziehung von AEM Forms Java-Bibliotheksdateien

Verbindungseigenschaften festlegen

Konvertieren eines PDF-Dokuments in eine RTF-Datei mithilfe der Webservice-API convert-a-pdf-document-to-a-rtf-file-using-the-web-service-api

Konvertieren Sie ein PDF-Dokument mithilfe der Generate PDF API (Webservice) in eine RTF-Datei:

Siehe auch

Zusammenfassung der Schritte

AEM Forms mithilfe von MTOM aufrufen

Aufrufen von AEM Forms mithilfe von SwaRef

Erweitern der Unterstützung auf weitere native Dateiformate adding-support-for-additional-native-file-formats

In diesem Abschnitt wird erläutert, wie Sie für weitere native Dateiformate eine Unterstützung hinzufügen. Dargeboten wird ein Überblick über die Interaktionen zwischen dem Generate PDF-Service und den nativen Programmen, die dieser Service zum Konvertieren nativer Dateiformate in PDF verwendet.

Außerdem wird in diesem Abschnitt Folgendes erläutert:

Interaktionen von Komponenten component-interactions

Der Generate PDF-Dienst konvertiert native Dateiformate, indem er das mit dem Dateiformat verknüpfte Programm aufruft und dann mit dem Programm interagiert, um das Dokument unter Verwendung des Standarddruckers zu drucken. Der Standarddrucker muss als Adobe PDF Printer eingerichtet sein.

Diese Abbildung zeigt die Komponenten und Treiber, die an der Unterstützung nativer Programme beteiligt sind. Außerdem sind die XML-Grammatiken vermerkt, die Einfluss auf die Interaktionen haben.

Komponenteninteraktionen bei der Konvertierung nativer Dateien

In diesem Dokument wird der Ausdruck natives Programm verwendet, um das Programm anzugeben, das zum Erzeugen eines nativen Dateiformats verwendet wird, wie beispielsweise Microsoft Word.

AppMon ist eine für Unternehmen konzipierte Komponente, die mit einem nativen Programm auf dieselbe Weise interagiert, wie ein Benutzer durch die von diesem Programm präsentierten Dialogfelder navigieren würde. Die XML-Grammatiken, die von AppMon verwendet werden, um ein Programm wie Microsoft Word anzuweisen, eine Datei zu öffnen und zu drucken, umfassen die folgenden nacheinander auszuführenden Aufgaben:

AppMon verwendet standardmäßige Win32-APIs, um mit Drittanbieteranwendungen zu interagieren und Benutzenden Benutzeroberflächen-Ereignisse wie Tastenanschläge und Mausklicks zu übermitteln. Dadurch werden diese Anwendungen so gesteuert, dass aus ihnen heraus PDF-Dateien erzeugt werden.

Aufgrund einer Einschränkung bei diesen Win32-APIs kann AppMon diese Benutzeroberflächenereignisse nicht an bestimmte Arten von Fenstern, wie z. B. unverankerte Menüleisten (in einigen Programmen, wie beispielsweise TextPad, enthalten) und bestimmte Arten von Dialogfeldern, deren Inhalt nicht mithilfe der Win32-APIs abgerufen werden kann, senden.

Eine unverankerte Menüleiste lässt sich leicht visuell erkennen. Gegebenenfalls ist es jedoch nicht möglich, die speziellen Dialogfeldtypen allein durch visuelle Überprüfung zu identifizieren. Sie würden ein Drittanbieterprogramm wie Microsoft Spy++ (Teil der Microsoft Visual C+±Entwicklungsumgebung) oder das äquivalente WinID (das kostenlos von https://www.dennisbabkin.com/php/download.php?what=WinID heruntergeladen werden kann) benötigen, um ein Dialogfeld darauf zu prüfen, ob AppMon unter Verwendung von Standard-Win32-APIs damit interagieren könnte.

Wenn WinID in der Lage ist, Dialogfeldinhalte wie Text, Unterfenster, Fensterklassen-ID usw. zu extrahieren, dann kann AppMon dies ebenfalls tun.

In dieser Tabelle sind die Informationstypen aufgeführt, die beim Drucken nativer Dateiformate verwendet werden.

Über XML-Dateien für Skripte und Dialogfelder about-the-script-and-dialog-xml-files

Skript-XML-Dateien weisen den Generate PDF-Service an, durch die Dialogfelder des Programms so zu navigieren, wie ein Benutzer durch die Dialogfelder des Programms navigieren würde. Skript-XML-Dateien können den Generate PDF-Service außerdem anweisen, auf Dialogfelder zu reagieren, indem sie beispielsweise auf Schaltflächen klicken, Kontrollkästchen aktivieren oder deaktivieren oder Menüelemente auswählen.

Im Gegensatz dazu reagieren XML-Dialogfelddateien einfach auf Dialogfelder mit den gleichen Aktionstypen, die in XML-Skript-Dateien verwendet werden.

Terminologie von Dialogfeld- und Fensterelementen dialog-box-and-window-element-terminology

In diesem und im nächsten Abschnitt wird je nach der beschriebenen Perspektive eine andere Terminologie für Dialogfelder und die darin enthaltenen Komponenten verwendet. Dialogfeldkomponenten sind Elemente wie Schaltflächen, Felder und Kombinationsfelder.

Dort, wo dieser und der nächste Abschnitt Dialogfelder und ihre Komponenten aus der Perspektive eines Benutzers beschreiben, werden Begriffe wie Dialogfeld, Schaltfläche, Feld und Kombinationsfeld verwendet.

Dort, wo dieser und der nächste Abschnitt Dialogfelder und ihre Komponenten aus der Perspektive ihrer internen Darstellung beschreiben, wird der Begriff Fensterelement verwendet. Die interne Darstellung von Fensterelementen ist eine Hierarchie, in der jede Fensterelementinstanz durch Beschriftungen identifiziert wird. Die Fensterelementinstanz beschreibt auch ihre physischen Merkmale und ihr Verhalten.

Aus Sicht der Benutzenden weisen die Dialogfelder und ihre Komponenten unterschiedliche Verhaltensweisen auf, wobei einige Dialogfeldelemente ausgeblendet sind, bis sie aktiviert werden. Aus der Sicht der internen Darstellung gibt es kein solches Verhaltensproblem. Beispielsweise sieht die interne Darstellung eines Dialogfelds ähnlich aus wie die der darin enthaltenen Komponenten, abgesehen davon, dass die Komponenten innerhalb des Dialogfelds verschachtelt sind.

In diesem Abschnitt werden XML-Elemente beschrieben, die AppMon Anweisungen geben. Diese Elemente haben Namen wie das dialog-Element und das window-Element. In diesem Dokument wird zur Unterscheidung von XML-Elementen eine Schriftart mit fester Zeichenbreite verwendet. Das dialog-Element identifiziert ein Dialogfeld, das durch eine XML-Skriptdatei absichtlich oder unabsichtlich angezeigt werden kann. Das window-Element bezeichnet ein Fensterelement (Dialogfeld oder die Komponenten eines Dialogfelds).

Hierarchie hierarchy

Dieses Diagramm zeigt die Hierarchie des Skript- und Dialog-XML. Eine XML-Skriptdatei entspricht dem Schema „script.xsd“, das (im Sinne von XML) das Schema „window.xsd“ enthält. Analog entspricht eine XML-Dialogfelddatei dem Schema „dialogs.xsd“, das ebenfalls das Schema „window.xsd“ enthält.

Hierarchie des Skripts und Dialogfeld-XML

XML-Skriptdateien script-xml-files

Eine XML-Skriptdatei gibt eine Reihe von Schritten an, die das native Programm anweisen, zu bestimmten Fensterelementen zu navigieren und dann Reaktionen auf diese Elemente bereitzustellen. Bei den meisten Reaktionen handelt es sich um Text oder Tastenanschläge, die den Eingaben entsprechen, die ein Benutzer in ein Feld, ein Kombinationsfeld oder eine Schaltfläche im entsprechenden Dialogfeld eingeben würde.

Die Unterstützung des Services „Generate PDF“ für XML-Skriptdateien soll dazu dienen, eine native Anwendung anzuweisen, eine native Datei zu drucken. XML-Skriptdateien können jedoch für alle Aufgaben verwendet werden, die Benutzende bei der Interaktion mit den Dialogfeldern der nativen Anwendung ausführen können.

Die Schritte in einer XML-Skriptdatei werden der Reihe nach ausgeführt, ohne die Möglichkeit einer Verzweigung. Der einzige unterstützte bedingte Test ist die Zeitüberschreitung/Wiederholung, wodurch ein Skript beendet wird, wenn ein Schritt nicht innerhalb eines bestimmten Zeitraums und nach einer bestimmten Anzahl weiterer Versuche erfolgreich abgeschlossen wird.

Die Anweisungen in einem Schritt sind nicht nur sequenziell, sondern werden auch der Reihe nach ausgeführt. Stellen Sie sicher, dass die Schritte und Anweisungen der Reihenfolge entsprechen, in der Benutzende diese Schritte ausführen würden.

Jeder Schritt in einer XML-Skriptdatei identifiziert das Fensterelement, das angezeigt werden soll, wenn die Anweisungen des Schritts erfolgreich ausgeführt wurden. Wird während der Ausführung eines Skriptschritts ein unerwartetes Dialogfeld angezeigt, durchsucht der Service „Generate PDF“ die XML-Dialogfelddateien, wie im nächsten Abschnitt beschrieben.

XML-Dialogfelddateien dialog-xml-files

Während der Ausführung nativer Programme werden verschiedene Dialogfelder angezeigt, die unabhängig davon erscheinen, ob sich die nativen Programme in einem sichtbaren oder unsichtbaren Modus befinden. Die Dialogfelder können vom Betriebssystem oder vom Programm selbst erstellt werden. Wenn native Programme unter der Kontrolle des Service „Generate PDF“ ausgeführt werden, werden die Dialogfelder des Systems und des nativen Programms in einem unsichtbaren Fenster angezeigt.

Eine XML-Dialogfelddatei gibt an, wie der Service „Generate PDF“ auf die Dialogfelder des Systems oder des nativen Programms antwortet. Die XML-Dialogfelddateien ermöglichen es dem Service „Generate PDF“, so auf unaufgeforderte Dialogfelder zu reagieren, dass der Konvertierungsprozess erleichtert wird.

Wenn das System oder das native Programm ein Dialogfeld anzeigt, das nicht von der derzeit ausgeführten XML-Skriptdatei verarbeitet wird, durchsucht der Service „Generate PDF“ die XML-Dialogfelddateien in dieser Reihenfolge und stoppt, wenn er eine Übereinstimmung findet:

Wenn der Service „Generate PDF“ eine Übereinstimmung für das Dialogfeld findet, schließt er es, indem er ihm die für das Dialogfeld angegebene Tastenanschlag oder eine andere Aktion sendet. Wenn in den Anweisungen für das Dialogfeld eine Abbruchmeldung angegeben wird, beendet der Service „Generate PDF“ den derzeit ausgeführten Auftrag und erzeugt eine Fehlermeldung. Eine solche Abbruchmeldung würde im abortMessage-Element in der XML-Skriptgrammatik angegeben.

Wenn der Generate PDF-Dienst auf ein Dialogfeld stößt, das in keiner der oben aufgeführten Dateien beschrieben wird, fügt er die Beschriftung des Dialogfelds in den Protokolldateieintrag ein. Der derzeit ausgeführte Auftrag wird schließlich mit einer Zeitüberschreitung beendet. Sie können dann die Informationen in der Protokolldatei verwenden, um neue Anweisungen in der zusätzlichen XML-Dialogfelddatei (additional) für das native Programm zu erstellen.

Hinzufügen oder Ändern der Unterstützung für ein natives Dateiformat adding-or-modifying-support-for-a-native-file-format

In diesem Abschnitt werden die Aufgaben beschrieben, die Sie ausführen müssen, um andere native Dateiformate zu unterstützen oder um die Unterstützung eines bereits unterstützten nativen Dateiformats zu ändern.

Bevor Sie Unterstützung hinzufügen oder ändern können, müssen Sie die folgenden Aufgaben ausführen.

Auswahl eines Tools zum Identifizieren von Fensterelementen choosing-a-tool-for-identifying-window-elements

In den XML-Dateien für Dialogfelder und Skripte müssen Sie das Fensterelement (Dialogfeld, Feld oder andere Dialogfeldkomponente) identifizieren, auf das Ihr Dialogfeld oder Skriptelement reagiert. Wenn beispielsweise ein Skript ein Menü für ein natives Programm aufruft, muss das Skript das Fensterelement in diesem Menü identifizieren, auf das Tastatureingaben oder eine Aktion angewendet werden sollen.

Sie können ein Dialogfeld einfach anhand der Beschriftung identifizieren, die in der Titelleiste angezeigt wird. Sie müssen jedoch ein Tool wie Microsoft Spy++ verwenden, um Fensterelemente auf einer niedrigeren Ebene zu identifizieren. Die Fensterelemente einer niedrigeren Ebene können durch eine Vielzahl von Attributen identifiziert werden, die nicht offensichtlich sind. Außerdem kann es sein, dass jedes native Programm sein Fensterelement anders identifiziert. Daher gibt es mehrere Möglichkeiten, ein Fensterelement zu identifizieren. Im Folgenden finden Sie die empfohlene Reihenfolge, in der die Identifizierung von Fensterelementen erfolgen sollte:

Jedes dieser drei Attribute kann zur Identifizierung eines Fensters verwendet werden.

Wenn die Attribute eine Beschriftung nicht identifizieren können, können Sie stattdessen ein Fensterelement identifizieren, indem Sie dessen Index in Bezug auf dessen übergeordnetes Element verwenden. Ein index gibt die Position des Fensterelements relativ zu den gleichrangigen Fensterelementen an. Häufig sind Indizes die einzige Möglichkeit, Kombinationsfelder zu identifizieren.

Seien Sie sich dieser Dinge bewusst:

Wenn Sie mit Dialogfeld- oder Skript-XML-Dateien arbeiten möchten, sollten Sie das Programm Microsoft Spy++ installieren.

Dekomprimieren der Dialogfeld- und Skriptdateien unpackaging-the-dialog-and-script-files

Die Dialogfeld- und Skriptdateien befinden sich in der Datei „appmondata.jar“. Bevor Sie eine dieser Dateien ändern oder neue Skript- oder Dialogfelddateien hinzufügen können, müssen Sie diese JAR-Datei entpacken. Angenommen, Sie möchten Unterstützung für das Programm EditPlus hinzufügen. Sie erstellen zwei XML-Dateien mit den Namen „appmon.editplus.script.de_DE.xml“ und „appmon.editplus.script.additional.de_DE.xml“. Diese XML-Skripte müssen zur Datei „adobe-appmondata.jar“ an zwei Stellen hinzugefügt werden, wie unten angegeben:

Nachdem Sie diese XML-Dateien zur Datei „adobe-appmondata.jar“ hinzugefügt haben, müssen Sie die GeneratePDF-Komponente erneut bereitstellen. Führen Sie die folgenden Aufgaben aus, um Dialogfeld- und Skript-XML-Dateien zur Datei „adobe-appmondata.jar“ hinzuzufügen:

So stellen Sie die GeneratePDF-Komponente erneut bereit

Erstellen oder Ändern einer XML-Skript-Datei für ein natives Programm creating-or-modifying-a-script-xml-file-for-a-native-application

Wenn Sie Dateien an ein neues natives Programm weiterleiten möchten, müssen Sie eine XML-Skript-Datei für dieses Programm erstellen. Wenn Sie ändern möchten, wie der Generate PDF-Service mit einem bereits unterstützten nativen Programm interagiert, müssen Sie das Skript für dieses Programm ändern.

Das Skript enthält Anweisungen, die durch die Fensterelemente des nativen Programms navigieren und jeweils spezifische Antworten für diese Elemente bereitstellen. Die Datei, die diese Informationen enthält, lautet appmon.[appname]`` .script.[locale].xml. Ein Beispiel ist „appmon.notepad.script.de_DE.xml“.

Identifizieren der Schritte, die das Skript ausführen muss identifying-steps-the-script-must-execute

Ermitteln Sie mithilfe des nativen Programms die Fensterelemente, durch die Sie navigieren müssen, und jede Antwort, die Sie zum Drucken des Dokuments ausführen müssen. Notieren Sie sich die Dialogfelder, die aus einer Antwort resultieren. Die Schritte ähneln den folgenden Schritten:

Identifizieren der in Beschriftungsattributen angegebenen Dialogfelder identifying-the-dialogs-specified-in-caption-attributes

Verwenden Sie Microsoft Spy++, um die Identitäten der Fensterelementeigenschaften im nativen Programm abzurufen. Sie müssen über diese Identitäten verfügen, um Skripte zu schreiben.

Verwenden regulärer Ausdrücke in Beschriftungsattributen using-regular-expressions-in-caption-attributes

Sie können reguläre Ausdrücke in Beschriftungsspezifikationen verwenden. Der Generate PDF-Service verwendet die java.util.regex.Matcher-Klasse, um reguläre Ausdrücke zu unterstützen. Dieses Dienstprogramm unterstützt die regulären Ausdrücke, die unter java.util.regex.Pattern beschrieben werden.

Regulärer Ausdruck, der den Dateinamen unterstützt, dem im Editor-Banner Notepad vorangestellt wird

 <!-- The regular expression ".*Notepad" means any number of non-terminating characters followed by Notepad. -->
 <step>
     <expectedWindow>
         <window caption=".*Notepad"/>
     </expectedWindow>
 </step>

Regulärer Ausdruck, der Druck von der Druckeinrichtung unterscheidet

 <!-- This regular expression differentiates the Print dialog box from the Print Setup dialog box. The "^" specifies the beginning of the line, and the "$" specifies the end of the line. -->
 <windowList>
     <window controlID="0x01" caption="^Print$" action="press"/>
 </windowList>

Sortieren von window- und windowList-Elementen ordering-the-window-and-windowlist-elements

Ordnen Sie die window- und windowList-Elemente wie folgt an:

Sortieren von Fensterelementen in einer Dialogfelddatei

 <!-- The caption attribute in the following window element is 40 characters long. It is the longest caption in this example, so its parent window element appears before the others. -->
 <window caption="Unexpected Failure in DebugActiveProcess">
     <…>
 </window>

 <!-- Caption length is 33 characters. -->
 <window caption="Adobe Acrobat - License Agreement">
     <…>
 </window>

 <!-- Caption length is 33 characters. -->
 <window caption="Microsoft Visual.*Runtime Library">
     <…>
 </window>

 <!-- The caption attribute in the following window element is 28 characters long. It is the shortest caption in this example, so its parent window element appears after the others. -->
 <window caption="Adobe Acrobat - Registration">
     <…>
 </window>

Sortieren von Fensterelementen in einem windowList-Element

 <!-- The caption attribute in the following indexes element is 56 characters long. It is the longest caption in this example, so its parent window element appears before the others. -->
 <windowList>
     <window caption="Can&apos;t exit design mode because.* cannot be created"/>
     <window className="Button" caption="OK" action="press"/>
 </windowList>
 <windowList>
     <window caption="Do you want to continue loading the project?"/>
     <window className="Button" caption="No" action="press"/>
 </windowList>
 <windowList>
     <window caption="The macros in this project are disabled"/>
     <window className="Button" caption="OK" action="press"/>
 </windowList>

Erstellen oder Ändern einer zusätzlichen XML-Dialogfelddatei für ein natives Programm creating-or-modifying-an-additional-dialog-xml-file-for-a-native-application

Wenn Sie ein Skript für ein natives Programm erstellen, das zuvor nicht unterstützt wurde, müssen Sie auch eine zusätzliche XML-Dialogfelddatei für dieses Programm erstellen. Jedes native Programm, das von AppMon verwendet wird, darf nur eine zusätzliche XML-Dialogfelddatei haben. Die zusätzliche XML-Dialogfelddatei ist auch dann erforderlich, wenn keine unangeforderten Dialogfelder erwartet werden. Das zusätzliche Dialogfeld muss mindestens ein window-Element enthalten, selbst wenn dieses window-Element lediglich ein Platzhalter ist.

Sie können für folgende Zwecke auch die zusätzliche XML-Dialogfelddatei für ein natives Programm ändern:

Der Dateiname, der eine zusätzliche dialogXML-Datei angibt, lautet appmon.[appname].addition.[locale].xml. Ein Beispiel ist „appmon.excel.additional.de_DE.xml“.

Der Name der zusätzlichen XML-Dialogfelddatei muss das Format appmon.[applicationname].addition.[locale].xml verwenden, wobei applicationname genau mit dem in der XML-Konfigurationsdatei und im Skript verwendeten Programmnamen übereinstimmen muss.

Ordnen Sie die windowList-Elemente an, die als untergeordnete Elemente in einem window-Element erscheinen. (Siehe Sortieren von window- und windowList-Elementen.)

Ändern der allgemeinen XML-Dialogfelddatei modifying-the-general-dialog-xml-file

Sie können die allgemeine XML-Dialogfelddatei ändern, um auf vom System generierte Dialogfelder zu reagieren oder auf Dialogfelder zu reagieren, die für mehrere Programme gelten.

Hinzufügen eines Dateitypeintrags in der XML-Konfigurationsdatei adding-a-filetype-entry-in-the-xml-configuration-file

In diesem Verfahren wird beschrieben, wie Sie die Konfigurationsdatei des Generate PDF-Services aktualisieren, um Dateitypen mit nativen Programmen zu verknüpfen. Um diese Konfigurationsdatei zu aktualisieren, müssen Sie die Konfigurationsdaten mithilfe von Administration Console in eine Datei exportieren. Der standardmäßige Dateiname für die Konfigurationsdaten lautet „native2pdfconfig.xml“.

Aktualisieren der Konfigurationsdatei des Generate PDF-Services

In diesem Beispiel wurden die mit dem Generate PDF-Service bereitgestellten Standardkonfigurationsdaten geändert, um anzugeben, dass nicht Microsoft Word, sondern Notepad zur Verarbeitung von Dateien mit der Dateierweiterung .txt verwendet werden soll. Vor dieser Änderung wurde Microsoft Word als das native Programm angegeben, das solche Dateien verarbeiten soll.

Änderungen für die Weiterleitung von Textdateien an Notepad (native2pdfconfig.xml)

 <filetype-settings>

 <!-- Some native app file types were omitted for brevity. -->
 <!-- The following GenericApp element specifies Notepad as the native application that should be used to process files that have a txt file name extension. -->
             <GenericApp
                 extensions="txt"
                 name="Notepad" displayName=".*Notepad"/>
             <GenericApp
                 extensions="wpd"
                 name="WordPerfect" displayName="Corel WordPerfect"/>
             <GenericApp extensions="pmd,pm6,p65,pm"
                 name="PageMaker" displayName="Adobe PageMaker"/>
             <GenericApp extensions="fm"
                 name="FrameMaker" displayName="Adobe FrameMaker"/>
             <GenericApp extensions="psd"
                 name="Photoshop" displayName="Adobe Photoshop"/>
         </settings>
     </filetype-settings>

Erstellen einer Umgebungsvariablen zum Auffinden des nativen Programms creating-an-environment-variable-to-locate-the-native-application

Erstellen Sie eine Umgebungsvariable, die den Speicherort der ausführbaren Datei des nativen Programms angibt. Die Variable muss das Format [applicationname]_PATH haben, wobei applicationname exakt mit dem in der XML-Konfigurationsdatei und im Skript verwendeten Programmnamen übereinstimmen muss und der Pfad den Pfad zur ausführbaren Datei in doppelten Anführungszeichen enthält. Ein Beispiel für eine solche Umgebungsvariable ist Photoshop_PATH.

Nachdem Sie die neue Umgebungsvariable erstellt haben, müssen Sie den Server neu starten, auf dem der Generate PDF-Service bereitgestellt wird.

Erstellen einer Systemvariablen in der Windows XP-Umgebung

Erstellen einer Systemvariablen über die Befehlszeile

XML-Dateien xml-files

AEM Forms enthält XML-Beispieldateien, die dazu führen, dass der Generate PDF-Service Notepad zur Verarbeitung von Dateien mit der Dateinamenerweiterung .txt verwendet. Dieser Code ist in diesem Abschnitt enthalten. Darüber hinaus müssen Sie die anderen in diesem Abschnitt beschriebenen Änderungen vornehmen.

Zusätzliche XML-Dialogfelddatei additional-dialog-xml-file

Dieses Beispiel enthält die zusätzlichen Dialogfelder für das Notepad-Programm. Diese Dialogfelder können zusätzlich zu den vom Generate PDF-Service angegebenen Dialogfeldern angezeigt werden.

Editor-Dialogfelder (appmon.notepad.additional.de_DE.xml)

 <dialogs app="Notepad" locale="en_US" version="7.0" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="dialogs.xsd">
     <window caption="Caption Title">
         <windowList>
             <window className="Button" caption="OK" action="press"/>
         </windowList>
     </window>
 </dialogs>

XML-Skriptdatei script-xml-file

In diesem Beispiel wird angegeben, wie der Generate PDF-Service mit Editor interagieren soll, um Dateien mithilfe des Adobe PDF-Druckers zu drucken.

XML-Skriptdatei für Editor (appmon.notepad.script.de_DE.xml)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!--
*
* ADOBE CONFIDENTIAL
* ___________________
* Copyright 2004 - 2005 Adobe Systems Incorporated
* All Rights Reserved.
*
* NOTICE:  All information contained herein is, and remains
* the property of Adobe Systems Incorporated and its suppliers,
* if any.  The intellectual and technical concepts contained
* herein are proprietary to Adobe Systems Incorporated and its
* suppliers and may be covered by U.S. and Foreign Patents,
* patents in process, and are protected by trade secret or copyright law.
* Dissemination of this information or reproduction of this material
* is strictly forbidden unless prior written permission is obtained
* from Adobe Systems Incorporated.
*-->

<!-- This file automates printing of text files via notepad to Adobe PDF printer. To see the complete hierarchy Adobe recommends using the Microsoft Spy++ which details the properties of windows necessary to write scripts. In this sample there are total of eight steps-->

<application name="Notepad" version="9.0" locale="en_US" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="scripts.xsd">

    <!-- In this step we wait for the application window to appear -->
    <step>
        <expectedWindow>
            <window caption=".*Notepad"/>
        </expectedWindow>
    </step>

    <!-- In this step, we acquire the application window and send File->Open menu bar, menu item commands and the expectation is the windows Open dialog-->
    <step>
        <acquiredWindow>
            <window caption=".*Notepad">
                <virtualInput>
                    <menuBar>
                        <selection>
                            <name>File</name>
                        </selection>
                        <selection>
                            <name>Open...</name>
                        </selection>
                    </menuBar>
                </virtualInput>
            </window>
        </acquiredWindow>
        <expectedWindow>
            <window caption="Open"/>
        </expectedWindow>
    </step>

    <!-- In this step, we acquire the Open window and then select the 'Edit' widget and input the source path followed by clicking on the 'Open' button . The expectation of this 'action' is that the Open dialog will disappear -->
    <step>
        <acquiredWindow>
            <window caption="Open">
                <windowList>
                    <window className="ComboBoxEx32">
                        <windowList>
                            <window className="ComboBox">
                                <windowList>
                                <window className="Edit" action="inputSourcePath"/>
                                </windowList>
                            </window>
                        </windowList>
                    </window>
                </windowList>
                <windowList>
                    <window className="Button" caption="Open" action="press"/>
                </windowList>
            </window>
        </acquiredWindow>
        <expectedWindow>
            <window caption="Open" action="disappear"/>
        </expectedWindow>
        <pause value="30"/>
    </step>

    <!-- In this step, we acquire the application window and send File->Print menu bar, menu item commands and the expectation is the windows Print dialog-->
    <step>
        <acquiredWindow>
            <window caption=".*Notepad">
                <virtualInput>
                    <menuBar>
                        <selection>
                            <name>File</name>
                        </selection>
                        <selection>
                            <name>Print...</name>
                        </selection>
                    </menuBar>
                </virtualInput>
            </window>
        </acquiredWindow>
        <expectedWindow>
            <window caption="Print">
        </window>
        </expectedWindow>
    </step>

    <!-- In this step, we acquire the Print dialog and click the 'Preferences' button and the expected window in this case is the dialog with the caption '"Printing Preferences' -->
    <step>
        <acquiredWindow>
            <window caption="Print">
                <windowList>
                    <window caption="General">
                        <windowList>
                            <window className="Button" caption="Preferences" action="press"/>
                        </windowList>
                    </window>
                </windowList>
            </window>
        </acquiredWindow>
        <expectedWindow>
            <window caption="Printing Preferences"/>
        </expectedWindow>
    </step>

    <!-- In this step, we acquire the dialog "Printing Preferences' and select the combo box which is the 10th child of window with caption '"Adobe PDF Settings' and select the first index. (Note: All indeces start with 0.) Besides this we uncheck the box which has the caption '"View Adobe PDF results' and we click the button OK. The expectation is that 'Printing Preferences' dialog disappears. -->
    <step>
        <acquiredWindow>
            <window caption="Printing Preferences">
                <windowList>
                    <window caption="Adobe PDF Settings">
                        <windowList>
                            <window className="Button" caption="View Adobe PDF results" action="uncheck"/>
                        </windowList>
                        <windowList>
                            <window className="Button" caption="Ask to Replace existing PDF file" action="uncheck"/>
                        </windowList>
                    </window>
                </windowList>
                <windowList>
                    <window className="Button" caption="OK" action="press"/>
                </windowList>
            </window>
        </acquiredWindow>
        <expectedWindow>
            <window caption="Printing Preferences" action="disappear"/>
        </expectedWindow>
    </step>

    <!-- In this step, we acquire the 'Print' dialog and click the Print button. The expectation is that the dialog with caption 'Print' disappears. In this case we use the regular expression '^Print$' for specifying the caption given there could be multiple dialogs with caption that includes the word Print. -->
    <step>
        <acquiredWindow>
            <window caption="Print">
                <windowList>
                    <window caption="General"/>
                    <window className="Button" caption="^Print$" action="press"/>
                </windowList>
            </window>
        </acquiredWindow>
        <expectedWindow>
            <window caption="Print" action="disappear"/>
        </expectedWindow>
    </step>
    <step>
        <expectedWindow>
            <window caption="Save PDF File As"/>
        </expectedWindow>
    </step>
    <!-- Finally in this step, we acquire the dialog with caption "Save PDF File As" and in the Edit widget type the destination path for the output PDF file and click the Save button. The expectation is that the dialog disappears-->
    <step>
        <acquiredWindow>
            <window caption="Save PDF File As">
                <windowList>
                    <window className="Edit" action="inputDestinationPath"/>
                </windowList>
                <windowList>
                    <window className="Button" caption="Save" action="press"/>
                </windowList>
            </window>
        </acquiredWindow>
        <expectedWindow>
            <window caption="Save PDF File As" action="disappear"/>
        </expectedWindow>
    </step>

    <!-- We can always set a retry count or a maximum time for a step. In case we surpass these limitations, PDF Generator generates this abort message and terminates processing. -->
    <abortMessage msg="15078"/>
</application>