[GastForen Betriebsysteme und Dienste HELIOS Indesign PDF Export direkt auf Helios Volume, Problem!

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Themen
Beiträge
Moderatoren
Letzter Beitrag

Indesign PDF Export direkt auf Helios Volume, Problem!

meister eder
Beiträge gesamt: 1114

5. Mär 2008, 16:32
Beitrag # 1 von 16
Bewertung:
(5914 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo, ich habe folgendes Problem festgestellt.
Ich möchte aus Indesign (5.0.2, Mac 10.5.2) heraus direkt einen PDF Export in ein PDF Resolve Ordner machen, dieser liegt auf einem Helios UB Volume. Indesign bricht diesen Export mit einem Fehler "Der Export der PDF Datei ist Fehlgeschlagen!" ab. Schreibe ich das PDF auf den Desktop oder eine Ebene höher auf dem Helios Volume, dann funktionierts. Auch das nachträgliche reinkopieren der lokal erstellten Datei funktioniert einwandfrei. Folgendes habe ich schon getestet:
1. SMB mount des Helios Volumes, funktioniert!
2. Auf einem AFP Apple Server Tiger mount getestet, funktioniert auch!
3. lokal geschrieben danach reinkopiert, funktioniert!

Aus Grund 2 denke ich ein Helios Problem zu haben, aber welches? Auch habe ich schon die Namen verkürzt um die Länge des gesamten Pfades zu kürzen, hat aber nichts gebracht.

Die weitere Bearbeitung via PDF resolve funktioniert einwandfrei.

Für Eure Hilfe wäre ich sehr dankbar!
Eder
X

Indesign PDF Export direkt auf Helios Volume, Problem!

GreatOm
Beiträge gesamt: 378

6. Mär 2008, 13:13
Beitrag # 2 von 16
Beitrag ID: #340396
Bewertung:
(5886 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
InDesign scheint generell Probleme unter Mac OS X 10.5.x zu haben...

http://www.macfixit.com/...ry=20071204110627804:
Zitat Several users have reported an issue where InDesign CS3 crashes when attempting to open or save certain files or when launching the application under Mac OS X 10.5.x (though the latter may be conflated with the former, i.e. users invoking an application launch by opening afflicted files).


Gruß,

GreatOm


als Antwort auf: [#340261]

Indesign PDF Export direkt auf Helios Volume, Problem!

meister eder
Beiträge gesamt: 1114

12. Mär 2008, 07:56
Beitrag # 3 von 16
Beitrag ID: #341158
Bewertung:
(5842 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo, weitere Erfahrungen haben ergeben das dies auch unter 10.4.11 G5 Dualcore passiert! Als ist es kein reines Leo Problem! Hat dies mal jemand ausprobiert? Für Eure Hilfe wäre ich sehr dankbar.


als Antwort auf: [#340396]

Indesign PDF Export direkt auf Helios Volume, Problem!

Thomas Kaiser
  
Beiträge gesamt: 1299

12. Mär 2008, 08:45
Beitrag # 4 von 16
Beitrag ID: #341164
Bewertung:
(5835 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,

Antwort auf [ meister eder ] Als ist es kein reines Leo Problem!


Klar, es ist ein Problem maximal unklarer Kommunikation bzw. Problembeschreibung.

Antwort auf: Hat dies mal jemand ausprobiert?


Was eigentlich genau? Um was geht's eigentlich? Du schriebst ursprünglich von "PDF Resolve Ordner"? Was soll das sein?

Beschreib doch endlich einfach mal, einen völlig Unbeteiligten im Hinterkopf habend, was Du konkret machst, also bspw.:

Ich exportiere direkt aus InDesign (Version x.y) heraus in einen Ordner "xy", der auf einem Helios UB-Volume liegt, das von MacOS X x.y per AFP gemountet ist, und vom Skriptserver überwacht wird (mittels des Original-Helios-Skripts "pdfresolve.pl"). InDesign bricht aber immer (oder nur meist?) mit einer Fehlermeldung "xy" ab, parallel erscheint im scriptsrv.log auf dem Helios-Server Meldung "xy" ...

(dann würde ich Dich bspw. bitten, auf dem Server mal dies&das zu tun, um das Problem weiter einzugrenzen -- werd ich aber genau so lange nicht machen, wie Deine Anfragen und Antworten erkennen lassen, daß Du Forum-Beiträge nicht für die Allgemeinheit sondern nur für Dich selbst verfaßt, also remote Support eh nicht klappen kann und dann schon erst recht keine remote Kooperation)

Du sitzt vor Deinen Kisten, Du kannst dort in die Logs schauen, Du kannst Sachen von vorneherein ausschließen, etc. pp. Wir hier allerdings nicht. Insofern wäre es prickelnd, wenn Du Dir wirklich Antworten/Hilfestellung erhoffst, wenn Du nicht mit Dir sondern mit uns im Hinterkopf Anfragen und dito auch Antworten auf Rückfragen/Anregungen erstellen würdest.

Nur so als Tipp...

Gruss,

Thomas


als Antwort auf: [#341158]

Indesign PDF Export direkt auf Helios Volume, Problem!

swisscheese
Beiträge gesamt: 387

12. Mär 2008, 08:48
Beitrag # 5 von 16
Beitrag ID: #341166
Bewertung:
(5835 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo meister eder

Könnte es nicht sein, dass dir Helios UB (oder was auch immer in den PDF Resolve Ordner zugreift) das PDF "unter dem Hintern wegreisst", bevor es fertig geschrieben ist?

Gruss swisscheese


als Antwort auf: [#341158]

Indesign PDF Export direkt auf Helios Volume, Problem!

meister eder
Beiträge gesamt: 1114

13. Mär 2008, 09:12
Beitrag # 6 von 16
Beitrag ID: #341398
Bewertung:
(5782 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Thomas,

jetzt dachte ich diesmal ich hätte mir Mühe gegeben, aber es reicht nicht. Habe doch genau geschrieben was ich gemacht als auch schon ausgeschlossen habe.

Also ich bin etwas ratlos aber verstehe Dich auch, wenn ich auch nicht weiss wie ich es Dir bei meiner Fragestellung recht machen kann. Nur so nebenbei, es gibt hier viel schlimmer und spartanischer formulierte Fragen die nicht so kritisch kommentiert werden, aber wie dem auch sei, ich will es ja versuchen.

Ich habe auf einem Helios UB VOLUME einen Hotfolder der die PDF Resolve Funktion ausführt, überwacht via Helios UB Scriptserver (pdfresolve.pl). Wenn ich direkt aus Indesign 3.0.1 einen PDF Export (PDF 1.4, OPI Bildersetzung) in diesen Folder starte bricht dieser Vorgang mit der schon genannten Fehlermeldung ab, unter Leo als auch unter Tiger was ich schon getestet habe. Schreibe ich dieses File eine Ebene höher, also nicht in den Hotfolder dann funzt es, schreibe ich es auf den Desktop und schiebe es manuell in den Hotfolder auf Helios funzt es auch.
Mounte ich dieses Volume als SMB, dann schreibe ich diese Datei direkt in diesen Hotfolder ohne Probleme. DA ich wissen wollte ob ich grundsätzlich ein AFP Problem habe, habe ich einen Tiger Xserver verwendet und dies auf einem nicht von Helios servierten AFP Volume zu testen, dies funz auch einwandfrei.


So ich hoffe dies etwas besser zum Ausdruck gebracht zu haben, klar formuliere ich es im ersten Moment als mein Problem da ich ja eines habe, muss mich mal daran gewöhnen dies etwas pauschaler zu gestalten.

Also der Wille ist da, geh nicht zu hart mit mir ins Gericht, habe doch wirklich ein deutlich besseres Posting hier gesetzt auch wenn es bei Dir nicht so ankam. ;-)


als Antwort auf: [#341166]

Indesign PDF Export direkt auf Helios Volume, Problem!

meister eder
Beiträge gesamt: 1114

13. Mär 2008, 09:14
Beitrag # 7 von 16
Beitrag ID: #341401
Bewertung:
(5781 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo swisscheese,

dies wäre eine Idee, obwohl dieser Ordner schon länger existiert und ich früher keine Probleme damit hatte. Ich könnte mal versuchen das Überwachungsscript auszuschalten ob dies damit zu tun hat, danke Dir. Teste es mal und melde mich wieder!

Eder


als Antwort auf: [#341166]

Indesign PDF Export direkt auf Helios Volume, Problem!

Thomas Kaiser
  
Beiträge gesamt: 1299

13. Mär 2008, 12:00
Beitrag # 8 von 16
Beitrag ID: #341468
Bewertung:
(5769 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Moin,

Antwort auf [ meister eder ] Ich habe auf einem Helios UB VOLUME einen Hotfolder der die PDF Resolve Funktion ausführt, überwacht via Helios UB Scriptserver (pdfresolve.pl).


Wunderbar, also Scriptserver involviert. D.h. Du kannst per HELIOS oder EtherShare Admin (oder idealerweise direkt auf dem Server [1]) im scriptsrv.log nachgucken, was der Server zur Thematik meint.

Antwort auf: Wenn ich direkt aus Indesign 3.0.1 einen PDF Export (PDF 1.4, OPI Bildersetzung) in diesen Folder starte bricht dieser Vorgang mit der schon genannten Fehlermeldung ab, unter Leo als auch unter Tiger was ich schon getestet habe.


So weit, so schlecht. Aber das Spannende ist doch, daß hier der scriptsrv involviert ist, der ggf. einen "close"-Event für die Datei zu früh bekommt, dann anfängt, die Datei zu verarbeiten und dabei auf die Fresse fällt, weil die Datei bspw. noch gar nicht fertig ist.

Ich kenne einige Installationen, wo man den scriptsrv gar nicht benutzen kann, weil er viel zu häufig zu früh bzw. viel schlimmer gar nicht auf Dateien anschlägt und man deshalb null Produktionssicherheit mehr hat. Im ersteren Fall (zu früher close-Event) findest Du aber alles Nötige im scriptsrv.log (im zweiten Fall muß man genauer nachgucken, was aber nur was für Leute mit bisserl Übung in der Shell ist [2] und was man besser unterläßt, wenn man sich nicht sicher ist, was man tut)

Antwort auf: Schreibe ich dieses File eine Ebene höher, also nicht in den Hotfolder dann funzt es


Also in dem Moment auch kein scriptsrv involviert.

Antwort auf: schreibe ich es auf den Desktop und schiebe es manuell in den Hotfolder auf Helios funzt es auch.


Also in dem Fall nicht InDesign damit beauftragt, die Datei in den Hotfolder zu kopieren, sondern der Finder. Das kann sich massiv hinsichtlich der seitens des Macs generierten "low level"-Events unterscheiden, d.h. kann ein völlig anderes Ergebnis haben, wann der scriptsrv die Datei als fertig kopiert betrachtet und das für den Hotfolder konfigurierte Skript antritt.

Antwort auf: Mounte ich dieses Volume als SMB, dann schreibe ich diese Datei direkt in diesen Hotfolder ohne Probleme.


Grundsätzlich immer ganz, ganz schlecht, parallel auf die selben Volumes per AFP und SMB gemischt zuzugreifen (weil andere Repräsentation von Finder-Metadaten und Resourceforks). Das ist im Fall von Hotfoldern zwar regelmäßig wurscht, sollte man sich aber grundsätzlich abgewöhnen, weil es zu nichts als Ärger führt.

Dann stellt sich die Frage: Wie wird dieser SMB-Zugriff realisiert? Setzt Ihr PCShare auf dem Helios-Server ein oder wird der Hotfolder via Samba (oder sonstwie?) freigegeben? Grundsätzlich sollte immer PCShare benutzt werden aber man kann nicht davon ausgehen, daß es überall so ist. Drum ist diese Information wichtig.

Antwort auf: DA ich wissen wollte ob ich grundsätzlich ein AFP Problem habe, habe ich einen Tiger Xserver verwendet und dies auf einem nicht von Helios servierten AFP Volume zu testen, dies funz auch einwandfrei.


Inwiefern? Wie kriegst Du auf einem "nicht von Helios servierten AFP Volume" einen Hotfolder zum laufen, hinter dem das gleiche psresolve.pl Skript steckt? Also was hast Du damit eigentlich getestet bzw. meinst Du, getestet zu haben?

Antwort auf: So ich hoffe dies etwas besser zum Ausdruck gebracht zu haben


Doch, schon viel besser Smile

Antwort auf: klar formuliere ich es im ersten Moment als mein Problem da ich ja eines habe


Es geht nicht darum, wer das Problem hat, sondern wem das Problem verständlich gemacht werden soll. Wenn Du hier in die Runde fragst, dann solltest Du das Problem so schildern, daß es auch hier verständlich ist. Also von Leuten nachvollzogen werden kann, die weder Dein Setup, noch das, was Du als "selbstverständlich" oder "geht gar nicht" ansiehst, kennen, noch irgendwas von dem, was bei Dir auf den Kisten passiert, vor ihren Augen haben.

Das setzt dezentriertes Denken voraus (in die Position eines unbekannten Dritten versetzen und das Ganze versuchen, aus seiner Perspektive, d.h. absolut null Vorwissen und keine Möglichkeit, etwas direkt zu sehen, zu betrachten) und hilft mir regelmäßig, ein Problem soweit einzugrenzen, daß ich es selbst lösen kann. Genau diese Formulierung eines technischen Sachverhalts für einen imaginären und völlig unbeteiligten Dritten, hilft oft, ein strukturiertes Problembild überhaupt aufzubauen. Meines Erachtens fällt bei sowas sofort auf, daß ein Test auf ein beliebiges AFP-Volume (ohne involvierten Skriptserver) keinerlei Aussagekraft hat.

Und was für potentielle Helfer hier im Forum evtl. viel wichtiger ist: Anhand der Formulierung eines Problems erkennt man, wie strukturiert der Fragesteller vorgeht (also "Ich habe mir das angeschaut, ich habe das und das probiert, ich komme bis hierhin und weiß nicht weiter" versus "Hilfe, nix geht, Deadline im Rücken, keine Zeit genauer nachzuschauen. Helft mir gefälligst!" -- beliebige Grauabstufungen zwischen beiden Positionen möglich).

Und kann sich dann überlegen, ob man nachhakt (weil der Fragesteller signalisiert, daß er so und so weit ist und sich auch darauf einläßt, Vorschläge zur Eingrenzung nachzugehen) oder es besser gleich bleiben läßt, weil der Fragesteller signalisiert, daß er null Eigenleistung zu einer weiteren Eingrenzung erbringen wird und nur auf Lösungsansätze aus dem Forum aus ist, die ihn ggf. weiterbringen.

Beide Ansätze sind ja aus Perspektive des Fragestellers auch in Ordnung. Wie viel Erfolg man mit welchem hat, merkt man ja dann an Anzahl und Qualität der Antworten. Und ich zumindest antworte im Regelfall nur, wenn mich die Fragestellung an sich interessiert und abzusehen ist, daß man durch Beschäftigung mit dem Problem zu interessanten Erkenntnissen kommt.

Antwort auf: Also der Wille ist da, geh nicht zu hart mit mir ins Gericht, habe doch wirklich ein deutlich besseres Posting hier gesetzt auch wenn es bei Dir nicht so ankam. ;-)


Yo, man kann den Willen tatsächlich erkennen Smile. Und von wegen "ins Gericht gehen". Ich schreib halt ohne Rücksicht auf Verluste, was ich denke. Andere denken sich ihren Teil und antworten einfach nicht. Letzten Endes ging's mir bei meiner Kritik nicht darum, auf Dir rumzuhacken sondern nur aufzuführen, was mir inhaltlich an Deinen Problembeschreibungen fehlt bzw. was mich hindert, mich der Sache anzunehmen.

Ich hoffe, es kommt immer wenigstens noch teilweise als konstruktive Kritik an, auch wenn ich mich nicht sonderlich bemühe, Kritik in Watte zu packen, weshalb das wohl meist "zu harsch formuliert" ankommt. Ist aber nicht meine Intention. Für reines Bashing wär' mir meine Zeit zu schade. Geht schon darum, was zum Positiven zu ändern Smile

Gruss,

Thomas

[1] Auf dem Server kann man sich das ScriptServer-Log live anzeigen lassen per
Code
read HELIOSDIR </etc/HELIOSInstallPath  
tail -f $HELIOSDIR/var/adm/scriptsrv.log


[2] Um sich beliebige File-Events anzugucken, kann man direkt auf dem HELIOS-Server eine Verbindung mit localhost auf Port 2002 aufbauen und sich für quasi "alles" per "registertype \0\0\0\0" registrieren. [b]Achtung: Wenn man das macht, kann es sein, daß man die Event-Schnittstelle "überlastet", d.h. sowohl die Funktionalität des Skriptsrvs stört als auch ggf. OPI-Erzeugung blockiert, etc. Empfiehlt sich also für das Debugging von solchen Problematiken eigentlich nur in ruhigen Phasen und nach Studium des ImageServer Manuals diesbzgl.

Eine Beispiel-Session sieht übrigens so aus:
Code
telnet localhost 2002 
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
0 - Welcome to the HELIOS ImageServer event listener
registertype \0\0\0\0
0 - OK
4 - close "/var/volumes/webshare/test-tk/IMG_0710.eps"
4 - close "/var/volumes/webshare/test-tk/AN_Wojtek Czyz.xpv"
quit
0 - shutting down
Connection closed by foreign host.

Wenn viel auf dem Server los ist, muß man das "quit" zum Verlassen des Dienstes quasi blind tippen, weil einem vor lauter Events, die gelistet werden, keine Kontrolle mehr über die Eingabe neuer Befehle bleibt. Evtl. nix für schwache Nerven und nichts, was man auf einem eh schon am Anschlag laufenden Server machen sollte!


als Antwort auf: [#341398]

Indesign PDF Export direkt auf Helios Volume, Problem!

meister eder
Beiträge gesamt: 1114

13. Mär 2008, 16:06
Beitrag # 9 von 16
Beitrag ID: #341542
Bewertung:
(5755 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Vielen Dank für Deine ausführliche und konstruktive Kritik, wie gesagt habe es schon verstanden und bin für Eure/Deine Hilfe dankbar.

Mit dem SMB Mount den ich über PCShare machte wollte ich nur Probleme mit AFP ausschliessen, dennoch ist das Verhalten seltsam.

Ich habe nämlich den Scriptserver deaktiviert und danach ging es einwandfrei, soweit so gut den Scriptserver als Problem lokalisiert.

Aber nach der Deaktivierung habe ich ihn wieder aktiviert und siehe da, es läuft ohne Probleme, er schein irgendwie einen Hänger gehabt zu haben, wobei andere Scripte Ihren Dienst tun.

Mir stellt sich jedoch die Frage warum es vorher über den PCShare SMB Mount lief, aber naja ich bin ja froh das es wieder geht und Danke Euch recht herzlich.

Eder


als Antwort auf: [#341468]

Indesign PDF Export direkt auf Helios Volume, Problem!

swisscheese
Beiträge gesamt: 387

13. Mär 2008, 16:27
Beitrag # 10 von 16
Beitrag ID: #341553
Bewertung:
(5749 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Thomas

Was mich zu diesem Thema eigentlich noch interessieren täte: wie merkt denn der Skriptserver, ob eine Datei "fertig" ist oder nicht? Offensichtlich ist es ja ein Perl-Skript, das womöglich mit einem cron oder sonstwie regelmässig angestossen wird.

Meine Erfahrungen mit Skripts, die Hotfolder überwachen, sind diese: Das Skript listet sich einfach die Dateien auf die drin sind und "los geht's". In all den tollen Workflows wird nie überprüft, ob die Datei z.B. noch wächst (was ja ein sicheres Indiz ist, dass sie noch nicht angefasst werden sollte). Bei grösseren Dateien ist es dann dem Zufall überlassen, ob sie vor dem nächsten Skriptaufruf schon fertig sind oder nicht.

Ist das auch bei pdfresolve.pl so?

Gruss swisscheese

(Helios UB, ImageServer)


als Antwort auf: [#341542]

Indesign PDF Export direkt auf Helios Volume, Problem!

Thomas Kaiser
  
Beiträge gesamt: 1299

13. Mär 2008, 17:21
Beitrag # 11 von 16
Beitrag ID: #341568
Bewertung: |||
(5741 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,

Antwort auf [ swisscheese ] Was mich zu diesem Thema eigentlich noch interessieren täte: wie merkt denn der Skriptserver, ob eine Datei "fertig" ist oder nicht? Offensichtlich ist es ja ein Perl-Skript, das womöglich mit einem cron oder sonstwie regelmässig angestossen wird.


Nein, nein, nein. Völlig falsch.

Der Skriptserver war vor Ewigkeiten mal ein Perl-Skript, das sich auf den Helios OPI-Event Port (Port 2002) geklemmt hat. Inzwischen ist es ein vollwertiges Binary.

Die Funktionsweise hat auch nix mit cron oder sonstwie "regelmäßig anstoßen" zu tun sondern ist Event-basiert.

D.h. Anwendung speichert auf den Server, bei Helios schlagen die entsprechenden "close"-Events auf und nach einer Vorfilterung der Events werden dann vom Scriptserver die entsprechenden für den Dateipfad und Dateityp konfigurierten Skripte angestoßen.

D.h. es braucht kein stures doofes Polling der Hotfolder, es braucht kein regelmäßiges Überwachen (weshalb man mit dem Scriptserver ja auch Terabyte-große Volumes überwachen kann ohne daß die Performance irgendwie leidet, weil eben kein Skript im Hintergrund permanent den Server abgrast) sondern der Skriptserver kriegt das alles quasi passiv mit (gemeldet von PCShare bzw. EtherShare bzw. auf Windows von einem Helios-eigenen File-Event-Treiber)

Antwort auf: Meine Erfahrungen mit Skripts, die Hotfolder überwachen, sind diese: Das Skript listet sich einfach die Dateien auf die drin sind und "los geht's". In all den tollen Workflows wird nie überprüft, ob die Datei z.B. noch wächst (was ja ein sicheres Indiz ist, dass sie noch nicht angefasst werden sollte). Bei grösseren Dateien ist es dann dem Zufall überlassen, ob sie vor dem nächsten Skriptaufruf schon fertig sind oder nicht.


Das ist die Definition von "maximal dämlicher Hotfolder". Natürlich muß eine intelligente Lösung gucken, ob die Datei größer 0 Byte ist, ob sie noch wächst, etc. (jede gute Hotfolder-Lösung macht das auch so, sei sie nun Polling-basiert, d.h. permanentes aktives Gucken in einen Ordner oder Event-basiert per passiver Benachrichtigung)

All das versucht Helios auch beim Scriptserver mit abzufangen. Gelingt ihnen aber nicht immer, teils auch weil sich am Client (also bspw. dem Finder) was ändert. Mit irgendeinem 10.4.x Update bspw. hat der Finder, wenn man paar hundert Dateien auf den Server kopiert hat, erstmal für alle Dateien kleine 0 Byte große Dateien angelegt und dann in einem zweiten Lauf erst die eigentlichen Dateien draufkopiert. Bspw. schließt ein Photoshop oder ein InDesign beim Speichern einer Datei diese mehrfach, schreibt dann ein paar Blöcke, öffnet wieder, schließt wieder, etc. (Risiko dabei: Erkennen, wann die Datei wirklich "fertig" gesichert wurde)

Das zu erkennen, ist das, was ich oben mit "Filtern von Lowlevel-Events" gemeint habe. Klappt meist aber nicht immer.

Antwort auf: Ist das auch bei pdfresolve.pl so?


Mooooment. pdfresolve.pl ist kein Hotfolder. Es ist nur ein Skriptserver-Handler, also ein Programm, das vom Skriptserver aufgerufen wird (der Skriptserver kümmert sich um das Prozedere des Erkennen von Events und erst, wenn alles fertig ist, wird das passende Skript aufgerufen). D.h. da ist null eigene Hotfolder-Funktionalität drin, denn die stellt ja bereits der Skriptserver zur Verfügung. Aber bedingt durch obige Problematik empfiehlt es sich evtl., in Skriptserver-Handlern bspw. drauf zu prüfen, ob die Datei größer 0 Byte ist, etc.

Hmm... es ist schon ein Kreuz, wie wenig bekannt ist, wie der ganze Kram eigentlich funktioniert und wie man von den Features profitieren kann -- und das sogar hier, wo sich eher interessierte Anwender herumtreiben, die vielfach informierter sind als so mancher Helios-"Fachhändler".

Aber insg. auch nicht verwunderlich bei dem Stellenwert, den die Propagierung der für den Endanwender nützlichen Funktionalität beim Hersteller und seinen Distributoren zu haben scheint: tendenziell eher wenig.

Gruss,

Thomas


als Antwort auf: [#341553]

Indesign PDF Export direkt auf Helios Volume, Problem!

Thomas Kaiser
  
Beiträge gesamt: 1299

13. Mär 2008, 17:52
Beitrag # 12 von 16
Beitrag ID: #341588
Bewertung:
(5732 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hi,

Antwort auf [ meister eder ] Aber nach der Deaktivierung habe ich ihn wieder aktiviert und siehe da, es läuft ohne Probleme, er schein irgendwie einen Hänger gehabt zu haben, wobei andere Scripte Ihren Dienst tun.


Wie schon geschrieben: Es kann da zu Konfusion gekommen sein bedingt dadurch, wie InDesign so ein PDF speichert (bspw. erst mal 0 Byte große Datei schreiben, dann bisserl im Sesselchen zurücklehnen, Pfeifchen rauchen, irgendwo anders temporäre Datei erstellen, dann wieder paar Bytes schreiben, erneut Close-Event senden, usw. usf.)

Ich persönlich finde solche Fälle spannend, weil man auf dem Weg bei Helios vielleicht mehr Sensibilisierung dafür erreichen kann, daß der Skriptserver nicht immer und überall zufriedenstellend funktioniert. Insofern wären nach wie vor Auszüge bzgl. beider Betriebsarten (geht und geht nicht) aus dem scriptsrv.log spannend...

Antwort auf: Mir stellt sich jedoch die Frage warum es vorher über den PCShare SMB Mount lief


Beim Zugriff via SMB kommt auf dem Mac ein anderes VFS-Modul als bei AFP zum Einsatz, was sowohl Unterschiede hinsichtlich der Speicherung von Daten auf Server-Volumes mit sich bringt (betrifft Finder-Metadaten und evtl. existente Resource-Forks) als auch hinsichtlich des Speichervorgangs an sich. Bspw. steht auf SMB-Volumes die "FPExchangeFiles"-Methode nicht zur Verfügung (bei Interesse siehe den Thread rund um http://groups.google.com/...msg/56848b82517c5f1a), was dann evtl. dazu führt, daß ein Mac-Programm auf einem SMB-Volume völlig anders speichert als auf ein AFP-Volume (im ersten Fall bspw. temporäre Datei lokal anlegen und dann in einem Rutsch auf dem Server ersetzen bzw. neu anlegen, im letzten Fall bspw. "schluckweise" neu erzeugen).

Müsste man sich alles mal mit einem Netzwerk-Sniffern genauer ansehen, wenn es denn ein echtes Problem wäre (ich werd's nicht freiwillig, d.h. abseits konkreter Beauftragung machen, weil ich genügend anderes um die Ohren habe)

Gruss,

Thomas


als Antwort auf: [#341542]

Indesign PDF Export direkt auf Helios Volume, Problem!

swisscheese
Beiträge gesamt: 387

13. Mär 2008, 22:01
Beitrag # 13 von 16
Beitrag ID: #341606
Bewertung:
(5723 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Thomas

Ich verbeuge mich tief und bedanke mich für Deine sehr ausführlichen, verständlichen Ausführungen. Ich sehe, ich muss mich da mal zünftig schlau machen, um unsere Investitionen etwas besser auszureizen.

Antwort auf [ Thomas Kaiser ] Das ist die Definition von "maximal dämlicher Hotfolder".

Haha, der ist gut! Ich werde das mal unserem Workflow-Lieferant unter die Nase reiben. Will jetzt keine Namen nennen, hat aber so komische :Doppelpunkte in den Produktenamen...

Gruss swisscheese


als Antwort auf: [#341568]

Indesign PDF Export direkt auf Helios Volume, Problem!

asendrowski
Beiträge gesamt: 15

14. Mär 2008, 10:49
Beitrag # 14 von 16
Beitrag ID: #341654
Bewertung:
(5689 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo,

für mich ist das korrekte Auslösen von Skripts die Aufgabe des Skriptservers, aber das ist ein anderes Thema.

Folgende Situationen habe ich in der Praxis schon erlebt und müssen von einem Skript überprüft bzw. abgefangen werden:

1. Skripts werden aufgerufen, obwohl Datei noch nicht vollständig ist.
2. Skripts werden für die gleiche Datei mehrfach aufgerufen.

Da die mitgelieferten Skripts dies meines Wissens nicht prüfen sind diese nur zum Test und als Vorlage für eigene Lösungen zu gebrauchen.

Durch das hochsetzen der Skript-Verzögerung in den "Skript Server Vorgaben" treten die genannten Probleme seltener auf. Der Wert wird vom Skriptserver aber erst nach einem restart (vielleicht reicht auch ein reconf) übernommen.

Gruß
Andreas


als Antwort auf: [#341568]

Indesign PDF Export direkt auf Helios Volume, Problem!

Thomas Kaiser
  
Beiträge gesamt: 1299

14. Mär 2008, 13:32
Beitrag # 15 von 16
Beitrag ID: #341703
Bewertung:
(5674 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hi Andreas,

Antwort auf [ asendrowski ] Folgende Situationen habe ich in der Praxis schon erlebt und müssen von einem Skript überprüft bzw. abgefangen werden:

1. Skripts werden aufgerufen, obwohl Datei noch nicht vollständig ist.


Bzw. übersetzt: "Zu früh den finalen Close-Event ausgelöst". Kenne ich vom Script Server bisher nur in der Variante der 0 Byte großen Dateien, wenn per Finder kopiert wird (ab MacOS X 10.4.x -- weiß nicht mehr genau)

Antwort auf: 2. Skripts werden für die gleiche Datei mehrfach aufgerufen.


Kenne ich bisher eigentlich auch nur in obigem Zusammenhang mit dem Finder und den erst 0 Byte großen Dateien, die dann am Ende des Kopiervorgangs quasi aus Sicht des Servers nochmal richtig kopiert werden. Sind meines Erachtens zwei Seiten einer "Medaille", die sich aber im Falle der "0 Byte Finder Dummys" recht simpel per Skriptsrv-Handler abfangen ließen (bzw. lassen -- ich hab in meine Skripte einen entsprechenden Check eingebaut und das klappt in der Regel 1a.

Ich kenne allerdings noch eine dritte Problemklasse: Dateien, für die kein Event ausgelöst wird seitens Skriptserver, also das zugeordnete Skript nie aufgerufen wird. Hängt man sich direkt auf den Event-Listener-Port, so sieht, man daß für diese Dateien absurd viele Low Level Events ausgelöst werden, die aber beim SkriptServer selbst nie dazu führen, daß ein endgültiger richtiger Event getriggert wird.

Hatte ich bisher aber nur unter Solaris...

Auf welcher Plattform treten denn die oben aufgeführten Probleme bei Dir auf?

Antwort auf: Da die mitgelieferten Skripts dies meines Wissens nicht prüfen sind diese nur zum Test und als Vorlage für eigene Lösungen zu gebrauchen.


Ja, leider. Helios sieht/sah die eigenen Skripte explizit nur als Inspirationsquelle und nicht als Rohmaterial, das man nur noch verfeinern müsste.

Gruss,

Thomas


als Antwort auf: [#341654]
X

Veranstaltungskalender

Hier können Sie Ihre Anlässe eintragen, welche einen Zusammenhang mit den Angeboten von HilfDirSelbst.ch wie z.B. Adobe InDesign, Photoshop, Illustrator, PDF, Pitstop, Affinity, Marketing, SEO, Büro- und Rechtsthemen etc. haben. Die Einträge werden moderiert freigeschaltet. Dies wird werktags üblicherweise innert 24 Stunden erfolgen.

pdf-icon Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.

Veranstaltungen
17.04.2024

Online
Mittwoch, 17. Apr. 2024, 10.00 - 10.30 Uhr

Webinar

Komplizierte, kleinteilige Aufträge; alles sehr speziell; seit Jahren bewährte Prozesse – da können wir nichts standardisieren und automatisieren! Das sagen viele Großformatdrucker – aber stimmt das wirklich, ist dem tatsächlich so? Günther Business Solutions und Impressed treten in einem Webinar den Gegenbeweis an. Experten beider Unternehmen zeigen, wie Großformatdrucker vom Einsatz zweier bewährter Lösungen profitieren können: • von advanter print+sign von Günther Business Solutions, dem ERP-System für den Großformatdruck, dass alle Phasen der Wertschöpfung im Large Format Printing abdeckt • von Impressed Workflow Server, der smarten PDF-Workflow-Lösung für Druckereien, die Datenmanagement, Preflight und Produktionssteuerung übernimmt Über die Kombination beider Lösungen können Großformatdrucker ihre Prozesse mit modernen Workflows Schritt für Schritt automatisieren – und so zügig deutliche Zeit- und Kosteneinsparungen realisieren. Das Webinar sollten Sie sich nicht entgehen lassen – damit Sie keine Effizienzpotenziale mehr liegen lassen. Melden Sie sich am besten gleich an, wir freuen uns auf Sie! PS: Melden Sie sich in jedem Fall an – sollten Sie zum Termin verhindert sein, erhalten Sie die Aufzeichnung.

kostenlos

Ja

Organisator: Impressed / Günther Business Solutions

https://www.impressed.de/schulung.php?c=sDetail&sid=326

Und es geht doch: Automatisierung im Großformatdruck!
Veranstaltungen
18.04.2024 - 19.04.2024

München
Donnerstag, 18. Apr. 2024, 13.00 Uhr - Freitag, 19. Apr. 2024, 13.00 Uhr

Infoveranstaltung 18. und 19. April 2024

Impressed und eProductivitySoftware zeigen Ihnen, wie Sie Ihre Softwareausstattung auf Kurs Richtung Zukunft bringen können. Es geht unter anderem um die unverzichtbare Offenheit der Systeme, um Schnittstellen und um Standardisierung. 18. April, Nachmittag: Wir geben wir einen Überblick über den Markt, vermitteln die Grundlagen der Automatisierung und erklären, wie Applikationen in Auftragsmanagement und Produktion reibungslos miteinander kommunizieren können. Beim gemeinsamen Abendessen ist Gelegenheit für entspannte Gespräche mit Ihren Kolleg:innen, mit den Experten von eProductivity und uns. 19. April, Vormittag: Wir stellen Ihnen Workflowlösungen wie den Impressed Workflow Server und das MIS Pace im Detail vor und zeigen Ihnen, wie alles perfekt zusammenspielt – vom Auftragseingang bis hin zur Weiterverarbeitung. Sie erfahren auch, welche Fragen Sie bei der Auswahl von Softwarelösungen für Ihren Betrieb stellen sollten (ein gutes Briefing für die kommende drupa).

18. und 19. April 2024
Euro 95,- * pro Teilnehmer zzgl. MwSt. inkl. Mittagessen/Pausengetränke
Zur Anmeldung: https://www.impressed.de/schulung.php?c=sDetail&sid=324

Ja

Organisator: Impressed / eProductivitySoftware

https://www.impressed.de/schulung.php?c=sDetail&sid=324

Die Zukunft der Druckindustrie ist völlig offen