Hallo,

HELIOS hat die neue Version der Server Solution Suite HELIOS UB2 veröffentlicht.

Alle Neuerungen gegenüber UB+ sind in den Release Notes und auf den HELIOS-Webseiten beschrieben:
http://www.helios.de/support/manuals/releaseUB2-d/
http://www.helios.de/web/DE/products/new-features.html

Ein Auszug neuer Features (Details in den Release Notes):

* EtherShare ist AFP 3.3-Server

* Mac-Clients mit OS X 10.7 werden unterstützt

* AFP over TCP/IP als Standard, AppleTalk nur noch optional

* Neue Serverplattformen: Red Hat Enterprise 6, Oracle Solaris 11, OS X 10.6

Anmerkung: OS X 10.7 als Serverplattform ist in Vorbereitung und kommt in Kürze als Update.

* Spotlight-kompatible Dateisuche nach Metadaten und Volltext-Inhalten für EtherShare, PCShare und WebShare

* Neue Authentifizierung gegenüber AD/PDC

* Volume-Freigaben für ausgewählte Benutzer

* PDF-Preflight basiert auf callas pdfToolbox5 CLI und ist kompatibel zu Adobe Acrobat X

* Erweiterte Preflight-Skripte mit HTML-Report

* Create PDF Server für Acrobat X

* WebShare zeigt Voransichten von MS Office-Dokumenten und mehrseitigen PDFs ohne ImageServer und PDF HandShake

* WebShare-Softproof mit Kommentaren und Freigabefunktion

* Anmerkungen für WebShare-Voransichten (PDF; MS-Office; Bilder; QuarkXPress und InDesign per XPV)

* Die gesamte Funktionalität für Softproof und Abstimmung ist in PrintPreview UB2 als Erweiterung für WebShare zusammengefasst

* Preview Plug-ins für InDesign CS5 und QuarkXPress 9

Anmerkung: Das Plug-in arbeitet mit InDesign CS5.5 (DVD-Version ohne Update), erst das InDesign-Update 7.5.1 verhindert die Arbeit mit dem Preview Plug-in. HELIOS ist bereits bei der Problemlösung und liefert in Kürze ein Update.

* Verarbeitung von TIFFs mit mehr als 32 Kanälen

* Tool Server für OS X 10.6 (10.7 in Vorbereitung, siehe Anmerkung zu Serverplattformen)

Viele Grüße
Matthias Fenske

----------------------------------------------------
Promo Datentechnik + Systemberatung GmbH
www.promo.de

Hallo Herr Fenske,

könnte man damit eine solche Lösung realisieren?
http://www.hilfdirselbst.ch/..._P477013.html#477013

Wenn ja, was wäre dann an Helios-Lizenzen erforderlich? Webshare vermute ich mal? PDF-Handshake? Dann wird es schon düster bei mir...

Gruß

Hallo Rohrfrei,

wenn du schon Switch hast, dann wohl auch ein Tool zum PDF prüfen, oder? Dann bräuchtest Du nur noch ein WebShare mit einer passenden Zahl an Benutzern. Per WebShare kannst Du den Web-Transfer realisieren.

Einfach Upload in einen Hotfolder, der von Switch überwacht wird. Der Rest sollte dann in bekannten Bahnen laufen.

Bei Bedarf kannst Du WebShare so erweitern (Action Script, Javc Script), dass die Datenlieferanten Meta-daten auswählen oder auch konfigurieren können.

Gruß
Oliver

Hallo rohrfrei,

Antwort auf [ rohrfrei ]

könnte man damit eine solche Lösung realisieren?
http://www.hilfdirselbst.ch/..._P477013.html#477013

einen PDF-Preflight per Webbrowser mit HTML-Report bietet WebShare mit PDF HandShake sozusagen out of the box.

Für eine Integration in einen Switch-Workflow benötigen Sie K-Swtich von Thomas Kaiser, vertrieben über impressed. (Das kann aber noch weitaus mehr.)

Antwort auf [ rohrfrei ]

Wenn ja, was wäre dann an Helios-Lizenzen erforderlich? Webshare vermute ich mal? PDF-Handshake? Dann wird es schon düster bei mir...

WebShare und PDF HandShake, da der Preflight Bestandteil von PDF HandShake ist.

Gruß, Matthias Fenske

Hallo,

danke für die Antworten.

Nein, ich habe noch kein Switch und auch noch keinen Preflight-Server. Bin aber kurz vor der Investitionsentscheidung. Da ich aber schon Helios habe und ich bei Preflight Callas gelesen habe, lag der Schluß nahe, einmal quer zu denken.

Ich werde mir von meinem Händler ein Angebot erstellen lassen und das mit dem online-Preflight via Switch vergleichen. Wenn es per Helios tatsächlich out-of-the-box möglich ist, dann wäre das ein starkes Argument. Auch, um überhaupt bei Helios zu bleiben.

Gruß

Antwort auf [ Matthias Fenske ]

Anmerkung: OS X 10.7 als Serverplattform ist in Vorbereitung und kommt in Kürze als Update.

Antwort auf [ Matthias Fenske ]

Anmerkung: Das Plug-in arbeitet mit InDesign CS5.5 (DVD-Version ohne Update), erst das InDesign-Update 7.5.1 verhindert die Arbeit mit dem Preview Plug-in. HELIOS ist bereits bei der Problemlösung und liefert in Kürze ein Update.

Beide Punkte sind gelöst. HELIOS hat die Updates gestern veröffentlicht.

Gruß, Matthias Fenske

Hallo,

Zitat

Zitat

Antwort auf [ rohrfrei ] Wenn ja, was wäre dann an Helios-Lizenzen erforderlich? Webshare vermute ich mal? PDF-Handshake? Dann wird es schon düster bei mir...

WebShare und PDF HandShake, da der Preflight Bestandteil von PDF HandShake ist.

damit ich meinem Händler die richtigen Fragen stellen kann, wären folgende Infos hilfreich:
reichen diese beiden Lizenzen tatsächlich schon dafür aus? Einen Datenupload wird man natürlich realisieren können. Und auch ein PDF-Preflight ist bestimmt möglich. Aber ist auch die Kombination dessen mit automatischer Rückmeldung an den Kunden wie im Impressed-Beispiel (ganz oben mein link) möglich? Bekommt der Kunde nach dem Datenupload via Webshare direkt im Browser einen Preflight-Bericht angezeigt, z.B. im HTML-Format, den der Callas-Server ja out-of-the-box erzeugen kann?

Wenn man den Callas-Toolbox-Server über Helios PDF-Handshake erworben hat, kann man den dann auch "normal" nutzen, als wenn ich das selber bei Callas kaufen würde? Ich könnte mir vorstellen, dass bei Helios "nur" die CLI-Version enthalten ist, d.h. ohne Benutzeroberfläche. Könnte das jemand bestätigen? Denn dann bräuchte ich ja für eine universelle Nutzung ja noch den Script-Server, oder? Aber wenn ich Script-Server lese, dann graut es mir, weil ich mit Scripten, Terminal u.ä. ja doch eher nicht so bewandert bin. Muss ich mir dann für jede Nutzung des Callas-Server über einen Hotfolder ein extra Script schreiben (lassen)? Das ist für mich eine wichtige Entscheidungsgrundlage, da ich von der Integration Callas-Server mit Switch doch recht angetan bin, was die benutzerfreundlichkeit betrifft. Eine kryptische Script-Umgebung á la Helios würde mich dann im Vergleich doch eher abschrecken. Bin halt doch nicht so der Admin.

Wo kann man sich das mal ansehen? Bei Helios-Deutschland ist nur WebShare alleine als Demo verfügbar. Bei dem französischen Händler ist schon ein wenig mehr möglich und auf dem Server dümpeln auch einige PDFs und Preflight-Reporte rum. Aber als live-demo habe ich das so nicht gefunden. Thomas Richard hats bestimmt, aber der kann mir das ja nicht verkaufen ;-)

Gruß

Hallo rohrfrei,

PDF HandShake beinhaltet eine Lizenz für Teile der pdfToolbox5 CLI, und zwar die Bereiche, die zuvor von pdfInspektor abgedeckt wurden. Dies sind die gesamte PDF-Prüfung und die Wandlung zu PDF/X bzw. /A. Ein GUI wie bei pdfToolbox Server für Windows und Mac OS X ist nicht enthalten.

Für die PDF-Prüfung über WebShare stehen zwei Verfahren zur Auswahl:

[1] Per WebShare Action Script, im Lieferumfang von PDF HandShake enthalten.

Der Anwender lädt ein PDF per WebShare hoch, markiert dieses PDF und ruft das Action Script im Menü auf. Hier stehen die Prüfprofile zur Verfügung, die Sie dafür bereitstellen. Nach der Prüfung wird ein HTML-Report erstellt und neben dem PDF abgelegt, sodass der Anwender dieses sofort zur Verfügung hat.

Hierfür benötigen Sie WebShare und PDF HandShake.

[2] Per Hotfolder. Hierfür ist dann auch ImageServer notwendig, da ein Script Server-Vorgang eingerichtet wird.

Dieses Verfahren ist empfehlenswert, wenn Sie dem Anwender nur eine einzige Prüfung zur Verfügung stellen und ihm den Aufruf des Action Scripts ersparen wollen. Ein entsprechender Hotfolder wird per WebShare dem Anwender freigegeben. Der Anwender lädt sein PDF hoch und die Prüfung beginnt umgehend. Der HTML-Report wird automatisch erzeugt, neben dem PDF abgelegt und steht dem Anwender zur Verfügung.

Hierfür benötigen Sie WebShare, PDF HandShake und ImageServer.

Gruß, Matthias Fenske

Antwort auf [ rohrfrei ]

Aber wenn ich Script-Server lese, dann graut es mir, weil ich mit Scripten, Terminal u.ä. ja doch eher nicht so bewandert bin. Muss ich mir dann für jede Nutzung des Callas-Server über einen Hotfolder ein extra Script schreiben (lassen)?

Ein entsprechendes Skript liefert HELIOS mit PDF HandShake mit aus. Das einzige, was Sie machen müssen, ist über den HELIOS Admin diesem Skript einen Hotfolder zuzuweisen und anschließend das gewünschte Prüfprofil in den Hotfolder zu kopieren. Damit kann das Skript natürlich auch mehrfach für unterschiedliche Prüfungen mit verschiedenen Hotfoldern verwendet werden.

Antwort auf [ rohrfrei ]

Wo kann man sich das mal ansehen? Bei Helios-Deutschland ist nur WebShare alleine als Demo verfügbar. Bei dem französischen Händler ist schon ein wenig mehr möglich und auf dem Server dümpeln auch einige PDFs und Preflight-Reporte rum. Aber als live-demo habe ich das so nicht gefunden. Thomas Richard hats bestimmt, aber der kann mir das ja nicht verkaufen

Aktuell gibt es zwei Möglichkeiten:

- Fragen Sie Ihren Fachhändler. Viele unserer Fachhändler haben einen eingerichteten WebShare Demo-Server.

- Nutzen Sie eine Testinstallation. HELIOS bietet einen kostenlosen Testdrive zum Download an. Dieser kann auf einem Mac oder Linux-PC, auch in einer virtuellen Box, installiert und getestet werden.

Sie können mich auch gerne dazu auf dem direkten Weg ansprechen (Promo).

Gruß, Matthias Fenske

Antwort auf [ rohrfrei ]

Ich könnte mir vorstellen, dass bei Helios "nur" die CLI-Version enthalten ist, d.h. ohne Benutzeroberfläche. Könnte das jemand bestätigen? Denn dann bräuchte ich ja für eine universelle Nutzung ja noch den Script-Server, oder? Aber wenn ich Script-Server lese, dann graut es mir, weil ich mit Scripten, Terminal u.ä. ja doch eher nicht so bewandert bin. Muss ich mir dann für jede Nutzung des Callas-Server über einen Hotfolder ein extra Script schreiben (lassen)?

Da gibt es mittlerweile auch den "klicki-bunti" Script Assistant (Details unter http://www.helios.de/...ptserver.html#a00156).

Für UB+ kann man sich den sogar frei herunterladen:
http://www.helios.de/viewart.html?id=987-en

Vielleicht hilft das ja weiter ;-)

Gruß,

GreatOm

Hi,

Antwort auf [ rohrfrei ]

damit ich meinem Händler die richtigen Fragen stellen kann, wären folgende Infos hilfreich:
reichen diese beiden Lizenzen tatsächlich schon dafür aus? Einen Datenupload wird man natürlich realisieren können. Und auch ein PDF-Preflight ist bestimmt möglich. Aber ist auch die Kombination dessen mit automatischer Rückmeldung an den Kunden wie im Impressed-Beispiel (ganz oben mein link) möglich? Bekommt der Kunde nach dem Datenupload via Webshare direkt im Browser einen Preflight-Bericht angezeigt, z.B. im HTML-Format, den der Callas-Server ja out-of-the-box erzeugen kann?

Nein, das war auch bei der Impressed-Lösung so nicht umgesetzt. Warum? Weil so ein Preflight dauernd kann, weil bspw. in Switch gerade noch 1.000 Jobs vor dem konkreten Prüfjob kommen, etc.

Die Impressed-Lösung hat die Daten entgegengenommen und mit Metadaten versehen in Switch geworfen. Dort wurde der Rest mit Switch-Bordmitteln abgefeiert und am Ende der User per eMail (ebenfalls Switch-Bordmittel) informiert, daß die Daten geprüft wurden, was das Ergebnis ist und unter welchem Link das/die Prüfergebnisse einsehbar waren (bzw. kann man aus Switch heraus auch Prüfberichte als Attachments an eMails anhängen lassen)

Mit WebShare ist ein Upload der zu prüfenden Daten möglich. Da die User sich am WebShare-Server authentifizieren müssen und dabei auch ein Set an Stammdaten abgerufen wird, ist die Übergabe dieser Daten an Switch ebenfalls möglich -- wenngleich nicht mit Bordmitteln, da muß man ein klein wenig skripten (lassen). D.h. aus WebShare heraus kommt man ganz simpel Richtung Switch, die Metadaten (Profil und Kontaktdaten des Users) würden dabei von einem Webshare-Skript als XML-"Sidecar"-Datei der bzw. den zu prüfenden XML-Dateien mitgegeben.

Ab da wäre das dann alles Switch-Bordmittel, d.h. die weitere Verarbeitung als auch Benachrichtigung des Users, wenn der Preflight fertig ist, funktionieren solo aus Switch heraus. Die geprüfte Datei kann im Erfolgsfall dann bereits in weitere Workflows geroutet werden, im Fehler- oder Warnungsfall zurückgehalten werden und die Prüfreports dem Anwender zur Verfügung gestellt werden (bspw. indem sie einfach in den Webshare-Sharepoint kopiert werden oder aber als Attachment an die Benachrichtigungs-Mail getackert werden -- auch in Switch parametrisierbar bzgl. Größte der Attachments)

Antwort auf:

Wenn man den Callas-Toolbox-Server über Helios PDF-Handshake erworben hat, kann man den dann auch "normal" nutzen, als wenn ich das selber bei Callas kaufen würde?

Man erwirbt bei Helios nur die Preflight-Komponente. Soweit ich weiß gibt es aber ein vergünstigtes Upgrade auf die Vollversion des pdfToolbox Server (bzw. der CLI-Version, denn die Server-Version mit GUI gibt es ja nur für MacOS X und Windows -- und Helios bedient ja alle Unix-Plattformen mit einer Version)

Antwort auf:

Ich könnte mir vorstellen, dass bei Helios "nur" die CLI-Version enthalten ist, d.h. ohne Benutzeroberfläche. Könnte das jemand bestätigen? Denn dann bräuchte ich ja für eine universelle Nutzung ja noch den Script-Server, oder?

Es kommt -- wie immer -- drauf an. Wenn die Helios-Server-Plattform bspw. MacOS X ist, man bei Callas die Toolbox hat "aufsperren" lassen (die Version, die Helios mitliefert, ist zwar auf Prüffunktionalität beschränkt. Aber es reicht ein anderer Lizenz-Code und man hat quasi die Vollversion an Bord) und PowerSwitch auf dem selben Rechner einsetzt, dann könnte man für die Toolbox nun auch die normalen Switch-Konfiguratoren einsetzen.

So ein Setup würde ich mir aber dreimal durch den Kopf gehen lassen, speziell da auch dabei ein paar Fallstricke lauern (bspw. dürfte Switch keinesfalls lokal auf die Helios-Volumes zugreifen sondern über einen loopback-AFP-Mount und das wiederum geht nur, wenn man Helios dazu bringt, AFP unter einem anderen als dem Standard-Port anzubieten). Zumal ist sowas auch unter Performance-Gesichtspunkten sehr genau zu prüfen, ob man sich das antun will.

Setzt man auf den unixoiden Helios-Plattformen die pdfToolbox ein und will diese "per GUI" nutzen (bspw. aus Switch heraus) und Switch-Server und Helios-Server laufen auf unterschiedlichen Servern, dann wird's kompliziert. Es ist möglich aber nur mit Zusatzprodukten (bspw. unserem k-switch, das eine Brücke zwischen Helios und PowerSwitch schlägt, und ein wenig Skripting, um eine flexible Ansteuerung der Toolbox hinzubekommen.

Antwort auf:

Aber wenn ich Script-Server lese, dann graut es mir, weil ich mit Scripten, Terminal u.ä. ja doch eher nicht so bewandert bin.

Da bist Du nicht allein

Antwort auf:

Muss ich mir dann für jede Nutzung des Callas-Server über einen Hotfolder ein extra Script schreiben (lassen)?

Nein, neben den im Thread schon genannten Varianten würde bei der Variante, die pdfToolbox auf dem Helios-Server laufen zu lassen und durch einen separaten PowerSwitch-Server ansteuern zu lassen, initial noch Skripting hinzukommen, um eine flexible Ansteuerung der pdfToolbox hinzubekommen. D.h. einmalig Programmieraufwand, der dann alle Eventualitäten abdeckt. Der Rest ist "Herumklicken in Switch" und Befüllen der Flows (bspw. per WebShare, um Externe anzubinden).

Aber: Für sowas braucht es natürlich einerseits irgendein Bindeglied zwischen PowerSwitch und Helios (bspw. k-switch). Und andererseits ist dieses "Herumklicken in Switch" etwas verharmlosend. Denn gerade, wenn man Switch effizient nutzen will, stellt man schnell fest, daß auch dort wieder Skripting zum Einsatz kommt (bspw. weil man an Grenzen stößt und die Übergabe von Parametern an externe Tools, wenn kein nativer Konfigurator vorhanden ist, nur noch über Skriptausdrücke sauber abzuwickeln ist. D.h. dann kommt man um ein wenig (Java-)Skript-Code in Switch nicht herum.

Antwort auf:

Wo kann man sich das mal ansehen?

Läßt sich vielleicht in einem kurzen Telefonat klären.

Gruss,

Thomas

Antwort auf [ Thomas Kaiser ]

Hi,

Nein, das war auch bei der Impressed-Lösung so nicht umgesetzt. Warum? Weil so ein Preflight dauernd kann, weil bspw. in Switch gerade noch 1.000 Jobs vor dem konkreten Prüfjob kommen, etc.

Die Impressed-Lösung hat die Daten entgegengenommen und mit Metadaten versehen in Switch geworfen. Dort wurde der Rest mit Switch-Bordmitteln abgefeiert und am Ende der User per eMail (ebenfalls Switch-Bordmittel) informiert, daß die Daten geprüft wurden, was das Ergebnis ist und unter welchem Link das/die Prüfergebnisse einsehbar waren (bzw. kann man aus Switch heraus auch Prüfberichte als Attachments an eMails anhängen lassen

Hallo Thomas,

das ist nur die halbe Wahrheit. :-)
Wir habe dem Anwender zwei Möglichkeiten angeboten, um das Preflight-Ergebnis zu erhalten. Variante 1 war die Zusendung des Reports per Email bzw. Email-Attachment (der Unterschied ist wichtig, da z.B. ein nach HTML konvertierter Report direkt als HTML-Email versendet werden könnte, ein PDF-basierter Prüfbericht dagegen nur als Attachment oder per Download-Link).

Variante 2 aber war tatsächlich die direkte Anzeige des HTML-basierten Prüfberichts im Webbrowser des Daten-Uploaders. Das Problem hierbei ist, dass nicht voraussagbar ist, wie lange die Report-Generierung dauern wird. Das heißt, man kann zwar ein Progress-Element in diese Webseite einbauen, damit der Anwender weiß, dass noch was passiert, aber man kann leider keinen echten Fortschrittsbalken (wie z.B. bei eigentlichen Upload der Daten) oder Countdown einbauen, da niemand wissen kann, wie lange dieser Prozess dauern wird. Dies ist von diversen Faktoren wie der Komplexität der Daten, dem eingesetzten Prüfprofil, der Serverauslastung, usw. abhängig.

Die Zusendung des Reports per Email ist unabhängig von der Timing-Problematik immer interessant, weil ja nicht immer der Daten-Uploader auch derjenige ist, der die Entscheidung trifft, ob ein Job ok ist oder nicht. In vielen Fällen hat der Uploader gar nicht die fachliche Qualifikation diese Entscheidung auf Basis eines Prüfberichts (egal wie einfach und intuitiv dieser aufgebaut ist) zu treffen. Wenn er im Upload-Formular die Email-Adresse eines Kollegen oder Externen angeben kann der in der Lage ist, diese Entscheidung zu treffen, dann ist damit auch dieses Problem gelöst.

Hallo Robert,

Antwort auf [ Robert Zacherl ]

Antwort auf [ Thomas Kaiser ]

Nein, das war auch bei der Impressed-Lösung so nicht umgesetzt. Warum? Weil so ein Preflight dauernd kann, weil bspw. in Switch gerade noch 1.000 Jobs vor dem konkreten Prüfjob kommen, etc.

Die Impressed-Lösung hat die Daten entgegengenommen und mit Metadaten versehen in Switch geworfen. Dort wurde der Rest mit Switch-Bordmitteln abgefeiert und am Ende der User per eMail (ebenfalls Switch-Bordmittel) informiert, daß die Daten geprüft wurden, was das Ergebnis ist und unter welchem Link das/die Prüfergebnisse einsehbar waren (bzw. kann man aus Switch heraus auch Prüfberichte als Attachments an eMails anhängen lassen

das ist nur die halbe Wahrheit. :-)
Wir habe dem Anwender zwei Möglichkeiten angeboten, um das Preflight-Ergebnis zu erhalten. Variante 1 war die Zusendung des Reports per Email bzw. Email-Attachment (der Unterschied ist wichtig, da z.B. ein nach HTML konvertierter Report direkt als HTML-Email versendet werden könnte, ein PDF-basierter Prüfbericht dagegen nur als Attachment oder per Download-Link).

Wobei diese Fallunterscheidung ja sogar Switch-intern vorgenommen werden könnte. PDF --> Attachment, HTML --> inline-HTML in Mail.

Antwort auf:

Variante 2 aber war tatsächlich die direkte Anzeige des HTML-basierten Prüfberichts im Webbrowser des Daten-Uploaders.

Ah, OK. Dann hatte ich das von Deiner Präsentation anno dazumals in Berlin falsch in Erinnerung. Danke für die Korrektur.

Antwort auf:

Das Problem hierbei ist, dass nicht voraussagbar ist, wie lange die Report-Generierung dauern wird.

Mitunter auch ein Grund, warum mir diese Variante als fast schon absurd vorkommt. Aber da bin ich wohl übersensibilisiert. Ich kann mir nicht vorstellen, vor dem Rechner zu sitzen und quasi pro-aktiv darauf zu warten, daß etwas fertig wird, dessen Dauer unbekannt ist. Zu hoher Nervfaktor

Ich muß übrigens selbst auch noch eine Korrektur anbringen: Man kann aus WebShare heraus auch ganz ohne Skripting Metadaten wie bspw. wem der Prüfreport zugesandt werden soll an Switch übergeben. Ganz simpel über den Ordnernamen.

Angenommen man definiert ein Verzeichnis "PDF prüfen", das von Switch überwacht wird, und legt eine Ebene darunter je Kunde ein Unterverzeichnis (das dann auch der jeweilige Sharepoint ist, auf den der Kunde zugriff hat) an, das passend benannt ist ("Kunde 1", "Kunde 2", etc.). Dann kann Switch beim Aufgreifen der Daten (bzw. Verzeichnishierarchie) anhand der Verzeichnisnamen auch Empfänger-Adressen zuordnen. Allerdings ist das natürlich eine eher statische Geschichte und deckt auch den Fall nicht ab, einen anderen Empfänger für den Prüfreport angeben zu können.

Für solche Sachen braucht's dann halt doch ein WebShare-ActionScript (die sind relativ simpel, können im Rahmen des Uploads aufgerufen werden und dann per HTML-Formular weitere Sachen abfragen wie bspw. Empfänger-Adresse oder auch das auszuwählende Prüfprofil, falls sowas nicht eh bereits im Workflow fest verdrahtet sein sollte).

Wobei wir hier inzwischen sehr gute Erfahrung mit "Custom XMP Panels" gemacht haben (siehe http://www.pdflib.com/...etadaten/xmp-panels/).

Idee dahinter: Man schickt seinen Kunden ein entsprechendes XMP-Panel (das ist bisserl XML, das dafür sorgt, daß in Adobe-Anwendungen anschl. im Dateiinformations-Dialog ein eigener Reiter auftaucht, in dem der Kunde Workflow-spezifische Daten eingeben kann). Die Kunden füllen diese Workflow-relevante Metadaten quasi offline in InDesign aus -- ab dem Moment stecken diese Daten in den ID-Dateien als XMP, dito in exportierten PDF-Dateien. Und können nativ in Switch ausgelesen werden ohne daß es einen erneuten Zwischenschritt bräuchte.

Vorteil: Upload geht schneller, weil Metadaten bereits vorausgefüllt sind. Nachteil: Keine Überprüfung der Metadaten während des Uploads sondern erst in Switch. Und relativ unflexibel, falls sich öfter Parameter auf Dienstleister-Seite ändern sollten (da man dann jedesmal ein neues XMP-Panel mit korrekt hinterlegten Metadaten verschicken müsste).

Und um nun den Bogen wieder zurück zum ursprünglichen Thema des Threads zu spannen: Diese XMP-Metadaten, die man mittels Custom XMP-Panels in den Dateien unterbringen kann, können ab UB2 mittels dessen Indexserver (siehe ab "Spotlight-Suche" in http://www.helios.de/viewart.html?id=1141-de) indiziert werden und stehen sowohl an den Clients (für Macs voll Spotlight-kompatibel, für Windows als Shell-Extension im Explorer als auch für Web-Anwender via WebShare) als auch dem Server zur Verfügung.

Wenn man das Potential von (custom) XMP erkannt hat und einem klar ist, daß einem so ein Helios-UB2-Server mittels des Index-Servers Zugriff auf alle XMP-Metadaten aller Dateien auf egal wie fetten Server-Volumes in Sekundenbruchteilen gewährleistet, dann braucht man gar nicht mehr so viel Phantasie, um sich die Konsequenzen für smarte Workflows ausmalen zu können.

Jedenfalls kommt die Unterstützung von Helios' Index-Server aus PowerSwitch heraus durch einen neuen k-switch-Konfigurator mit der nächsten Version nächstes Jahr.

Gruss,

Thomas

Hallo,

danke für die überaus informativen und hilfreichen Antworten und sorry, dass ich mich erst jetzt melde, bin aber etwas beschäftigt zur Zeit. Wenn ich darlege, von welchem Ausgangspunkt ich meine Frage hier im Helios-Board gestellt habe, dann wird evtl. meine zwischenzeitliche Entscheidung klar. Hoffe ich.

Im PDF-Board hadere ich ja seit längerer Zeit über eine Investiton in Pitstop- oder Callas-Toolbox-Server. Das möchte ich sowieso haben, wobei meine Entscheidung eigentlich klar in Richtung Callas tendiert. Muss da aber noch so einiges mit Callas(-Support) klären, da ich nach dem Update der PlugIn-Version von 4.5 auf 5 gleich mehrere Probleme habe. Auch habe ich im HTML-Report vom Callas-Server einen Fehler entdeckt. Der wäre mit Switch umgehbar, was ich auch durchaus bereit bin, ebenfalls zu investieren, was dann auf so einen Automation-Server hinauslaufen würde. Das empfinde ich schon als sehr leistungsstarkes Gespann mit dem ich die beiden von mir gewünschten Hauptaufgaben PDF-Preflight und Farbkonvertierungen auch mit DeviceLink-Profilen wahrscheinlich problemlos erledigen kann. Aber vor allem kann ich das auch bedienen und mir selber die Workflows nach meinem Gusto einrichten ohne auf Fremdhilfe angewiesen zu sein.

Mag sein, dass Helios leistungsstärker ist mit der CLI-Version des Callas-Servers aber das spielt für mich gegenwärtig keine Rolle, da ich nicht in der Liga wie diese "Alarm"-Druckereien unterwegs bin. Und wenn ich für die servergestützten Farbkonvertierungen den Helios'schen Callas-Server auch noch aufrüsten müsste, dann kann ich ihn ja auch gleich als Automation-Server kaufen. Zumal ich auch beim letzten Helios-Update meine Lizenz vom Image-Server gekickt habe, die ich bei den obigen Beschreibungen ja evtl. auch wieder neu lizenzieren oder updaten müsste. Zusammen mit den für mich komplexen Anpassungen, schreckt mich das eher ab. Eher vom Aufwand als von den Kosten, die aber bestimmt auch höher sein würden.

Interessant finde ich die Einschätzungen zu dem "Live-Report" als Feedback im Browserfenster. Da ist etwas wahres dran und ich werde das nochmals überdenken. Evtl. reicht auch ein simples PHP-Formular mit Upload-Funktion, welches dann vom Automation-Server bearbeitet wird. Mit der Hilfe von Switch ist dann ja schon viel möglich. Ich will da nochmal drüber nachdenken.

Gruß