ePDF 2.99-4 für GhostScript 9.10

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Antworten
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

ePDF 2.99-4 für GhostScript 9.10

Beitrag von Frank Wochatz »

Bei Ghostscript gab es in den letzten Versionen einige Veränderungen.

Ich habe jetzt mal ePDF an die neueste Version angepaßt.
epdf1.png
epdf1.png (12.35 KiB) 7862 mal betrachtet
PDFs für das Web

Früher wurde PDFOPT aus dem Ghostscriptpaket verwendet, um linearisierte PDFs zu erzeugen, die sich entsprechend besser aus dem Netz laden/streamen lassen. Das mußte bei der PDF Erstellung immer in einem zweiten Durchlauf gemacht werden, d.h. Tools wie ePDF oder auch Ghostview müssen eine Datei zweimal konvertieren. Das dauert, erstellt unnötige temporäre Dateien etc..

Glückerweise hat sich dies nun erledigt, da Ghostscript mit dem Parameter "-FastWebView" direkt bei der Erstellung eines PDFs die Datei entsprechend optimiert. ePDF unterstützt dies nun auch, dazu wurde die Option im Profilesetup "optimize" umbenannt in "Fast Web View", und ePDF intern entsprechend umgebaut.

Da es sich um einen neue/andere Technik handelt, werden im Acrobat-Reader die Dateien nicht als 'optimiert' angezeigt. Das kann man vernachlässigen.

Das alte PDFOPT ist in neuen GS Verisonen nun auch nicht mehr enthalten, und wird auch nicht mehr unterstützt. Man kann es aber angeblich bei Bedarf auch noch auf einer alten GS-Version rüberkopieren.


Farb-Mapping

Zwischenzeitlich hatte bei Ghostscript "UseCIEColor" nicht funktioniert. Dies ist jedoch notwendig zur Erstellung von PDF/A Dateien. PDF/A ist eine Konvention bzw. ein Standard für PDFs zur (Langzeit-) Archivierung, damit man auch in ein paar Jahren solche Dateien noch öffnen kann. Außerdem soll diese Funktion die Konvertierung von CMYK nach RGB vebessern. Jetzt geht das wieder, die Funktion wurde in ePDF reaktiviert.


Fixe

Anführende Backslash-Zeichen beim Zieldateinamen (die z.B. beim Drucken aus Mesa heraus auftauchten) werden nun automatisch entfernt.


Einstellungen

Leider wird die Struktur des GhostScript-Pakets immer komplizierter und aufgeblähter. Damit ePDF richtig läuft, müssen im Distiller-Setup zusätzliche Pfade eingetragen werden. Bei mir sieht das so aus:

Code: Alles auswählen

D:\gscript\gs9.10\lib;D:\gscript\gs9.10\resource\init;D:\gscript\gs9.10\resource\fonts;C:\psfonts
Das ist zwingend erforderlich, und gilt übrigens auch für GhostView (muß von Hand angepaßt werden).

Ghoptscript 9.10 gibt es hier:
https://dl.dropboxusercontent.com/u/764 ... 131231.zip

Für Ghostscript 9.10 ist weiterhin noch GCC473 im Libpath erforderlich:
http://www.os2site.com/sw/dev/gcc/gcc-4.7.3/gcc473.zip

Den ePDF Patch findet Ihr hier:
http://subsys.de/epdf/download/ePDF299-4.zip
(erfordert ein bereits installiertes ePDF:
http://subsys.de/ePDF/)
Benutzeravatar
hanno
Beiträge: 97
Registriert: Do 9. Jan 2014, 22:20

Beitrag von hanno »

Hallo Frank,

danke für die neue Version und die ausführliche Beschreibung! Funktioniert alles prima.

Noch zwei Bemerkungen:

1) In "About" steht als Datum der Version "März 2013".

2) Der von dir angegebene Pfad sieht im Prinzip gleich aus wie meiner, aber:

Von Frank: D:\gscript\gs9.10\lib;D:\gscript\gs9.10\resource\init;D:\gscript\gs9.10\resource\fonts;C:\psfonts

Von Hanno: C:\TOOLS\TXTMANIP\GSTOOLS\gs9.10\lib;C:\TOOLS\TXTMANIP\GSTOOLS\gs9.10\resource\init;C:\TOOLS\TXTMANIP\GSTOOLS\gs9.10\Resource\font;C:\TOOLS\TXTMANIP\GSTOOLS\fonts;d:\psfonts

Außer Laufwerken und Stamm-Pfad also gleich bis auf bei mir zusätzlich: "C:\TOOLS\TXTMANIP\GSTOOLS\fonts". Im diesem Ordner "Fonts" sind bei mir 176 Dateien (...\gs9.10\resource\fonts hat 35 Dateien).
Weißt du zufällig, ob dieser zusätzliche Ordner noch nötig ist (er stammt vermutlich aus einer früheren GS-Version so um die 8.x)?


Und noch etwas: Wenn unter "ePDF - Distiller setup" nur der Pfad zu GS angegeben werden müsste (zB "D:\gscript\gs9.10\") wäre das fein.
Normalerweise übernimmt doch jeder die Struktur von GS. Das heißt, ...\BIN, ...\LIB, ...\RESOURCE etc. liegen immer relativ zu Ausgangspfad gleich.
rbm
Beiträge: 25
Registriert: Do 2. Jan 2014, 16:45

Beitrag von rbm »

Bevor ich ePDF ausprobiere, eine Frage an Euch beide:
Funktioniert das Drucken bei Euch?
Ich habe GS9.10 genauso "installiert" wie das funktionierende GS9.04, in den Optionen die Einstellungen laut readme vorgenommen, wie bei GS9.04, auch das oben beschriebene Verzeichnis fonts dazukopiert.
Die Druckereinstellungen bei GS9.10 sind wie die bei GS9.04.
Wenn ich einen Druck starte kommt eine Meldung

GPL Ghostscript 9.10 (2013-08-30)
Copyright (C) 2013 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Unknown device: pswrite
Unrecoverable error: undefined in .uninstallpagedevice
Operand stack:
defaultdevice
gsapi_exit returns 0
DosFreeModule returns 12

und es wird nicht gedruckt.

Mein Englisch ist mangelhaft, deshalb kann ich das Problem nicht mit dem Portierer diskutieren.

Wißt Ihr Rat?
Benutzeravatar
hanno
Beiträge: 97
Registriert: Do 9. Jan 2014, 22:20

Beitrag von hanno »

Also bei mir funktioniert der Druck. Auch wenn ich den Pfad verwenden, den GSView als "Standard" angibt:
C:\TOOLS\TXTMANIP\GSTOOLS\gs9.10\lib;C:\TOOLS\TXTMANIP\GSTOOLS\fonts
(Die "Standard"-Pfade werden definiert indem man in GSView unter "Optionen/Konfiguration ..." entsprechend einträgt.)

Frank hat ja empfohlen, unter GSView dieselben Pfade als "Ghostscript-Suchpfad" anzugeben wie unter ePDF. Das ist also nach meinem Test (s.o.) nicht notwendig.

Aus deiner Fehlermeldung sehe ich jetzt aber, dass du vermutlich nicht DRUCKEN sondern KONVERTIEREN angewählt hast.
Nehme ich dort "pswrite", bekomme ich dieselbe Fehlermeldung. Verwende ich "ps2write" klappt es.
Bitte teste das einmal.

Schöne Grüße
Hanno
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hallo Hanno,
hanno hat geschrieben:danke für die neue Version und die ausführliche Beschreibung! Funktioniert alles prima.
Gut so! :)
1) In "About" steht als Datum der Version "März 2013".
Danke für den Hinweis, das Datum muß ich noch aktualisieren.
2) Der von dir angegebene Pfad sieht im Prinzip gleich aus wie meiner, aber:
....

Außer Laufwerken und Stamm-Pfad also gleich bis auf bei mir zusätzlich: "C:\TOOLS\TXTMANIP\GSTOOLS\fonts". Im diesem Ordner "Fonts" sind bei mir 176 Dateien (...\gs9.10\resource\fonts hat 35 Dateien).
Weißt du zufällig, ob dieser zusätzliche Ordner noch nötig ist (er stammt vermutlich aus einer früheren GS-Version so um die 8.x)?
Also ich habe das Verzeichnis auch, allerdings setze ich den Pfad wie beschrieben nicht - m.E. braucht man die Dateien auch nicht, solange man diese Schriftarten nicht benutzt. Ich benutze nur Schriften, die ich in C:\PSFONTS installiert habe, und ich benutze auch keine Schriftartenersetzung (was wohl mit GS auch irgenwie ginge).
Und noch etwas: Wenn unter "ePDF - Distiller setup" nur der Pfad zu GS angegeben werden müsste (zB "D:\gscript\gs9.10\") wäre das fein.
Leider verändern sich die Pfade, und ePDF ist ja eigentlich ganz bewußt so angelegt, dass mit mehreren GS Versionen arbeiten kann.
Normalerweise übernimmt doch jeder die Struktur von GS. Das heißt, ...\BIN, ...\LIB, ...\RESOURCE etc. liegen immer relativ zu Ausgangspfad gleich.
Die Verzeichnisse unter .\Ressource haben sich in der letzten Version geändert. Früher bei GS 8 gab es zB. \resource\Font noch nicht. Es ist allerdings wirklich etwas ungünstig mit diesen ganzen Pfaden, da die Länge der Befehlzeile begrenzt ist (imo 1024 Zeichen), und die Sache nun langsam zu einem Problem werden kann! Am besten wäre es, solange man nicht Veränderungen an Ghostscript selbst vornehmen will, wenn man alle Dateien in ein Verzeichnis wirft, und das dann übergibt. Ich werde mal testen ob, das geht.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

@RBM,

Ich nutze GS nur für die PDF Konvertierung, kann Dir da leider nicht weiterhelfen. Ich drucke immer mit Lucide. ePDF kann auch nicht drucken, das ist nur zur PDF Erstellung gedacht.

Ghostview benutze ich fast garnicht mehr. Das Programm wird auch nicht mehr an aktuelle GS Versionen angepaßt. Es geht wohl im Moment noch, aber neuere Features werden dann auch nicht mehr unterstützt.


@Hanno
Frank hat ja empfohlen, unter GSView dieselben Pfade als "Ghostscript-Suchpfad" anzugeben wie unter ePDF. Das ist also nach meinem Test (s.o.) nicht notwendig.
Diese Empfehlung habe ich ehrlich gesagt aus der Readme-Datei von Paul Smedley aus dem GS 9.10 Paket übernommen, ich habe es selbst nicht ausprobiert. 8-)
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Frank Wochatz hat geschrieben: Es ist allerdings wirklich etwas ungünstig mit diesen ganzen Pfaden, da die Länge der Befehlzeile begrenzt ist (imo 1024 Zeichen),
Bei CMD.EXE ist die Obergrenze sogar nur 300.
Frank Wochatz hat geschrieben: und die Sache nun langsam zu einem Problem werden kann!
Deshalb bevorzuge ich es mit der Umgebungsvariablen GS_LIB zu arbeiten: http://www.ghostscript.com/doc/9.10/Use ... _variables

Außerdem exististiert der Parameter @filename zum Einlesen einer Konfigurationsdatei: http://www.ghostscript.com/doc/9.10/Use ... ut_control
Andreas Schnellbacher
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Jo Andreas, das geht. Das hatten wir uns damals aber schon ganz gut so überlegt. Der Witz an einer (komfortablen) GUI ist ja gerade, sowas nicht zu benutzen. Ich ärgere mich immer wieder, wenn ich eine Programm installiere und dann neu booten muß, weil config.sys Änderungen (wie Environment- oder Path-Varaiblen) vorgenommen werden, oder wenn man das Programm mal verschiebt. Sowas ist eigentlich nie wirklich notwendig, ebenso wie Einträge in die os2.ini oder system.ini

Ich würde sogar so weit gehen, dass diese Pfadangaben komplett vermieden werden könnten, wenn die GS-Entwickler das mal vernünftig einbauen würden, so dass GS selbst seine eigene Filestruktur kennt und per default (solange nichts anderes gesetzt ist) relativ zur Postition von gs.exe die entsprechenden Bibliotheken findet. Das wären ein paar Zeilen Code...

Außerdem:
- kann ePDF mit mehreren GS Versionen arbeiten, die man einfach umschalten kann. Das hat den Hintergrund, dass in GS auch öfter mal in neuen Versionen bestimmte Sachen nicht mehr funktionieren (aka Bugs). Dann kann man je nach Bedarf wechseln. Für jede Version wäre eine andere Umgebung notwendig. Außerdem kollidierte die Umgebungsvariable mit anderen Programmen, die ev. eine andere Version von GS benutzen, da gabs damals mal einen Fall.
- wollten wir temporäre Dateien (wie Steuerdateien) soweit es geht vermeiden.
- kann ePDF alternativ auch mit der Umgebungsvariablen umgehen, so ist es zumindest eingebaut, ich muss das direkt mal testen.

Ich nehme mal an, Du arbeitest damit auf Kommandzeile, da macht sowas natürlich viel eher Sinn.
Bei CMD.EXE ist die Obergrenze sogar nur 300.
Also ich habs gerade getestet, der Aufruf aus ePDF ist z.Z. um die 960 Zeichen lang, davon werden 254 Zeichen für Pfade (Libs, Positionen der Zeildatei und Quelldatei) - funktioniert mit Standard-CMD.
Die kürzere Beschränkung liegt bei Befehlen aus Rexx (Rexxzeile). Das kann man umgehen, indem man den Befehl in Variablen aufteilt nach dem Schema:

a = "furchtbar langer String"
b = "zweiter langer String"
befehl = a || b
address cmd befehl

So macht das ePDF intern.

Siehe auch Rexx Tipps und Tricks:
The maximum length for a string constant in OS/2 REXX is 250. To use strings longer than 250 chars, split them into pieces less than 250 chars and concatenate them in a variable. (There's no limitation for the length of the contents of a variable in OS/2 REXX.)
960 Zeichen ist natürlich der Hammer, und wenn die Dateien sehr tief in Unterverzeichnissen liegen, wird es Probleme geben. Da muss ich mir was überlegen.

PS: komisch, in einem os2-Fenster kann man tatsächlich nur 300 Zeichen pasten... aus Rexx geht es aber.

PPS: übrigens überprüft ePDF die Länge des Befehls, und gibt einen Hinweis aus.
Dateianhänge
epdf-error-longcmd.png
epdf-error-longcmd.png (6.26 KiB) 7767 mal betrachtet
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Frank Wochatz hat geschrieben: Der Witz an einer (komfortablen) GUI ist ja gerade, sowas nicht zu benutzen. Ich ärgere mich immer wieder, wenn ich eine Programm installiere und dann neu booten muß, weil config.sys Änderungen (wie Environment- oder Path-Varaiblen) vorgenommen werden, oder wenn man das Programm mal verschiebt. Sowas ist eigentlich nie wirklich notwendig, ebenso wie Einträge in die os2.ini oder system.ini
Pfade installierter Anwendungen gehören natürlich nie in die CONFIG.SYS. In der OS2.INI darf höchstens ein Verweis auf den Installationspfad stehen, wenn das Installationssystem das nicht schon selbst sichert, und zwar so, dass dies für andere Anwendungen transparent ist. (WarpIN in der aktuellen Version ist dafür nicht gut geeignet.)

Ich versteh aber nicht, was Du gegen Umgebungsvariablen hast, die innerhalb von ePDF gesetzt werden. Wenn Du dann aus dieser Umgebung GhostScript startest, gelten diese auch dafür. Häufig finde ich aber eine Konfigurationsdatei besser geeignet. Diese könnte ja vor jedem Aufruf von GhostScript neu geschrieben und danach wieder gelöscht werden.
Frank Wochatz hat geschrieben: Ich würde sogar so weit gehen, dass diese Pfadangaben komplett vermieden werden könnten, wenn die GS-Entwickler das mal vernünftig einbauen würden, so dass GS selbst seine eigene Filestruktur kennt und per default (solange nichts anderes gesetzt ist) relativ zur Postition von gs.exe die entsprechenden Bibliotheken findet. Das wären ein paar Zeilen Code...
Klar, aber es geht ja auch so.
Frank Wochatz hat geschrieben: Außerdem:
- kann ePDF mit mehreren GS Versionen arbeiten, die man einfach umschalten kann. Das hat den Hintergrund, dass in GS auch öfter mal in neuen Versionen bestimmte Sachen nicht mehr funktionieren (aka Bugs). Dann kann man je nach Bedarf wechseln. Für jede Version wäre eine andere Umgebung notwendig. Außerdem kollidierte die Umgebungsvariable mit anderen Programmen, die ev. eine andere Version von GS benutzen, da gabs damals mal einen Fall.
Du meinst Umgebungsvariablen, die in der CONFIG.SYS gesetzt werden. Andere wirken nur lokal für die aus diesem Prozess aufgerufenen Prozesse.
Frank Wochatz hat geschrieben: - wollten wir temporäre Dateien (wie Steuerdateien) soweit es geht vermeiden.
Warum? Temporäre Dateien löscht doch z.B. Dein eZIP auch vernünftig.
Frank Wochatz hat geschrieben: - kann ePDF alternativ auch mit der Umgebungsvariablen umgehen, so ist es zumindest eingebaut, ich muss das direkt mal testen.

Ich nehme mal an, Du arbeitest damit auf Kommandzeile, da macht sowas natürlich viel eher Sinn.
Nein, das meinte ich nicht, siehe oben.

Besten Dank für Deine Tests und Deine Recherchen zum Thema max. Länge. Viele Details hatte ich schon wieder vergessen.
Andreas Schnellbacher
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Ok Andreas, ich bin mir nicht sicher ob eine Umgebungsvariable, die ich in Rexx setze, dann auch Bestand in einem gestarteten CMD hat, wenn das die gleiche Session ist wäre das die Lösung. Probiere ich aus...
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Ich habe jetzt Andreas Vorschlag umgesetzt, ePDF arbeitet jetzt intern mit GS_LIB.

D.h. für den Anwender, dass längere Verzeichnisse für Quell- und Zieldateien möglich sind. Die Pfade müssen im Distillersetup weiterhin angegeben werden.

.\ressource\fonts braucht man übrigens scheinbar ebensowenig wie .\fonts. Bei mir reicht nun aus:

Code: Alles auswählen

D:\gscript\gs9.10\lib;D:\gscript\gs9.10\resource\init;C:\psfonts
ePDF 2.99-5
Benutzeravatar
hanno
Beiträge: 97
Registriert: Do 9. Jan 2014, 22:20

Beitrag von hanno »

Hallo Frank!

Eine Frage zu ePDF und INI:
Wäre es für dich möglich, in der INI einen Punkt für sinngemäß "auto-convert" (also PDF-Erstellung gleich nach dem Öffnen automatisch durchführen) einzubauen?

Ich verwende ePDF u.a. um aus DBExpert heraus PDFs zu machen und nütze dort in Macros die Möglichkeit, die ePDF-INI zu manipulieren.
Funktionen für "auto-close" von ePDF oder auch für die Wahl des Ausgabeverzeichnisses hast du ja schon drinnen, das ist übrigens auch sehr hilfreich.

Schöne Grüße
Hanno
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hallo Hanno,

ich freu mich, dass Du ePDF benutzt. Aber wäre es für eine PDF Erstellung ohne Interaktion nicht sinnvoller, direkt Ghostscript anzusteuern? Du könntest aus der ePDF Ini auf die Parameter zugreifen. Oder benötigst Du spezielle ePDF-Funktionen? Falls ja kann ich Dir das Feature gerne bei Gelegenheit einbauen. Es kann aber trotzdem zu nowendiger Usereingaben kommen, zB. falls Dateien überschrieben werden sollen oder sonstige Probleme auftauchen.
Benutzeravatar
hanno
Beiträge: 97
Registriert: Do 9. Jan 2014, 22:20

Beitrag von hanno »

Hallo Frank!

Danke für deine Rückmeldung. Mit Ghostscript ginge es vermutlich auch, aber mit ePDF ist es einfacher, denn:
Ich benutze in DBExpert einen "Report" (=Ausdruck von Daten) und so ein Report kann auf verschiedene Drucker/Ausgaben geleitet werden
Drucke ich also auf den ePDF-Drucker, nimmt mir ePDF den PS-Druck, den Daimon, die Einstellmöglichkeiten des Druckers, etc. ab, was sehr praktisch ist.
Auch die Warnungsmeldung bei event. Überschreiben ist o.k. und gut.

Ein Problem sehe ich nur, wenn der Parameter für "auto-convert" in der INI gesetzt ist und aus irgendeinem Grund so bleibt, dann kommt man eigentlich nur noch durch direktes Aufrufen von ePDF an die Optionen (so sie dort eingebaut ist!), um den "auto-convert"-Parameter wieder umzuschalten eben über direkte Manipulation der INI. Ansonsten wird jedes PDF immer gleich erzeugt und User-Interventionen sind nicht möglich. Das ist aber logisch und eigentlich ist es ja gewollt, dass ePDF autom. die PDFs erzeugt, wenn ein Druckjob kommt.

Vielleicht gibt es ja auch eine elegante Lösung, um die Manipulation der INI-Datei zu umgehen, zB könnte ePDF auf einen bestimmten Modus umschalten, wenn der Name der zu druckenden Datei einen bestimmten Parameter enthält (zB Beginn mit @). Dann müsste in den Einstellungen von ePDF ein Bereich sein, der die gewünschten Parameter beinhaltet, die beim Auftreten einer solchen Datei gewünscht sind.
ZB, wenn eine Datei @DasIstEinReport.PS kommt, werden die Einstellungen "auto-convert", "auto-close" und "Destination-PathFileName" aus dem entsprechenden Optionen-Bereich verwendet (zufällig beinhaltet mein Beispiel genau die Parameter, die ich gebrauchen könnte ... ;) ).

Ich will da aber nicht, dass du massig Arbeit bekommst! Das sind nur Anregungen, die aus meinen Bedürfnissen entstanden sind.

Nochmals vielen Dank für dein "ePDF"!
Hanno
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Man könnte auch etwas wie "autorun" als Commandline-Parameter übergeben, und wenn ich mich nicht täusche hatte ich das sogar mal vor Jahren eingebaut. Ich finde nur die Doku nicht :), ist ja auch alles ein paar Jahre her - ich schaue heute Abend mal im Quellcode nach.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Ok, es ist schon eingbaut. Wenn Du ePDF aufrufst und den Parameter "-RUN" übergibst, sollte die PDF Konvertierung automatisch starten. Es passiert genau das gleiche, als wenn Du ePDF aufrufst und den OK Button drückst.

Du müßtest jetzt mal schauen, wie Du ePDF entsprechend aufrufst. Benutzt Du das printmon Script, kannst Du das einfach anpassen.

Wenn Du quePDF benutzt, könntest Du mal probieren:
/b Batch mode. ePDF will be started in batchmode.

Bin mir grad nicht sicher, was das bewirkt, könnte aber passen.

Falls das nicht geht könnten wir das über die ini machen. Dann würden wir aber noch ein Script benötigen, mit dem die Einstellung von außen (ohne ePDF zu starten) deaktiviert werden kann. Wäre machbar, abe rnicht so elegant.

Weitere Commandline-Parameter sind übrigens

-A:'[autor]'
-S:'[subject]'
-T:'[title]'
-K:'[keyword]'

(einfache Anführungszeichen sind Pflicht)

für die PDF-Doc Infos. Ich muß mal die Doku aktualisieren. :roll:
Benutzeravatar
hanno
Beiträge: 97
Registriert: Do 9. Jan 2014, 22:20

Beitrag von hanno »

o.k., probiert - und - es hat geklappt :)

Aber ich muss dazu das Print2PS.cmd ändern, denn ich kann aus DBExpert keine Parameter mitschicken (Um dort ein PDF zu erzeugen, muss ich die Ausgabe auf einen Drucker leiten.)
Möglich wäre nur, in einem Macro die cmd-Datei zu stoppen, zu manipulieren und zu starten und dann wieder retour, denn für andere PDF-Erstellungen sollten ja die ursprünglichen Einstellungen wieder vorhanden sein. Da ist aber die Variante mit der INI-Manipulation einfacher (wobei teilweise Timing-Probleme auftreten können, wenn ePDF noch nicht geöffnet ist, bevor die Parameter der INI schon wieder zurückgesetzt werden).

Möglich sollte sein, eine zweite Pipe (zB "\pipe\ePDF_autorun"), einen zweiten Drucker und eine zweite Print2PS.cmd (zB "Print2PS_autorun.cmd") zu machen. Dann könnte man je nach Bedarf die Jobs auf den gewünschten Drucker schicken.

Übrigens: Die INI-Datei-Variante hat noch den Vorteil, dass auch das pdf_dir manipuliert werden kann.

Die "weiteren Commandline-Parameter" (-A, -S, ...) sind nicht schlecht(!), aber für meine Zwecke nicht so wichtig, denn ich muss folgende Parameter setzen bzw. beeinflussen (=Zusammenfassung meiner speziellen Bedürfnisse):
- das Ausgabeverzeichnis (mache ich über die INI: pdf_dir)
- autoclose von ePDF (mache ich über die INI: autoclose)
- den Dateinamen für das PDF (funktioniert nur durch Umbenennen des Reports in DBExpert, weil dieser Name als Parameter an ePDF weitergereicht wird. Da wäre eine andere Lösung, zB eine Möglichkeit über die INI, viel schöner)
- autorun für die PDF-Erstellung (ginge über Manipulation der Print2PS.cmd bzw. wie oben beschrieben mit zwei Drucker-Objekten mit entsprechenden Einstellungen)

Ich mache mir gerne noch weiter Gedanken zu dem Thema, da musst du mir aber etwas Zeit lassen ;) , weil ich momentan auch so viel zu tun habe. Ich wollte nur etwas von mir hören lassen, weil du ja so prompt reagiert hast ... :D
Antworten