[Ab Comet 4.0.5 R20002] InDesign® erwartet, dass verwendete Bilder im lokalen Netz liegen oder direkt in Dokumente eingebettet werden. Bilder aus dem Internet (Stichwort Cloud) können von InDesign® nicht geladen werden. Die priint:comet Plugins bieten mit dem Plug-In URL Link und der Palette Web-Bilder eine Möglichkeit, auch Bilder aus dem Netz verwenden zu können. Bilder werden dafür zurerst lokal heruntergeladen und die Bildverknüpfung dann mit dieser lokalen Datei gemacht.

Achtung : Trotz aller Bemühungen kann es vorkommen, dass URLs nicht aufgelöst werden können. Nicht auflösbare URLs sind nicht Teil des WERK II Supportes! Wenden Sie sich in diesen Fällen gerne an unseren Support, aber bitte haben Sie Verständnis dafür, dass wir Erweiterungen in diesem Bereich als (kostenpfilchtige) Feature-Requests behandeln.

Die Bildrahmen enthalten alle nötigen Informationen, um die Bilder jederzeit aktualisieren zu können. Für die Abfrage, ob ein Bild noch aktuell ist, werden dabei jeweils nur wenige Bytes, die sogenannten Header-Informatione, vom Server geladen und mit lokalen Daten verglichen.

Beachten Sie bitte Eigentumsrechte und Lizenzen der verwendeten Bilder.

Die Palette Web-Bilder zeigt alle aus dem Netz geladenen Bilder des aktuellen Dokumentes und ihren jeweiligen Status an. Beim Aufklappen eines Eintrages werden die Rahmen angezeigt, die das jeweilige Bild verwenden.

Der Status des Bildes wird in der Wolke angezeigt:

Mit Hilfe des Menüs Ansicht -> Web Bilder Status können Sie den Status der Bilder auch an den Dokumentrahmen anzeigen lassen:

Durch Doppelklick auf die Wolken-Symbole der Palette werden aktuelle Bilder (grün) erneut überprüft und geänderte oder fehlende Bilder (orange oder blau) neu geladen.

Einfachklick in die Seitennummer wählt den Rahmen im Dokument aus. Folgende Zusatzoptionen werden dabei unterstützt:

Mit den Menüs der Palette können die Web-Bilder des Dokumentes überprüft, aktualisiert und gelöscht werden. Einzelne Bilder können mit Hilfe des Kontextmenüs Web-Bilder bearbeitet werden.

Um unnötigen Netzwerk-Verkehr zu vermeiden, werden Statusprüfungen der Web-Bilder nur auf Benutzeranfragen hin gemacht. Ein automatischer Abgleich wird nicht gemacht. Mit timer::document_start im AfterLogin-Skript (Panelstatement 92) können Sie eine automatische Überprüfung aber leicht selbst konfigurieren. In der Idle-Timer-Funktion des Dokumentes verwenden Sie zum Überprüfen der Web-Bilder die Funktion document::check_url_links.

Die für die Web-Bilder nötigen Daten können in der Palette Plug-ins -> Comet Admin -> Rahmen-Etiketten (Zusatzmodule statt Plug-ins in Versionen vor InDesign® 2025) angezeigt werden. Halten Sie dazu die SHIFT-Taste gedrückt und klicken Sie auf die Lupe oben rechts in der Palette.

Ist kein dokument-unabhängiger Zielpfad für die Bildablage definiert, müssen neue Dokumente vor dem Anlegen von Web-Bildern einmal gesichert werden damit ein Zielpfad für den Download bestimmt werden kann.

Zum manuellen Anlegen eines URL-Bildes gehen Sie wie folgt vor:

  1. Kopieren Sie die Bild-URL in die Zwischenablage.
  2. Wählen Sie den gewünschten Zielrahmen aus. Der Rahmen darf auch ein Textrahmen sein - in diesem Fall wird der Textinhalt vor dem Verknüpfen des Bildes gelöscht!
  3. Wählen Sie eine der folgenden Aktionen

Die cScript-Funkion frame::image, Rahmenplatzhalter für Bildrahmen und die TaggedText-Tags <in>, <w2inline> und <graphicell> erkennen selbständig, ob eine übergebene Bildadresse eine URL ist und legen bei Bedarf automatisch Web-Bilder an.

Mit Hilfe der seit v3.2.1 verfügbaren Möglichkeit, URL-Ereignisse durch die priint:comet Plug-ins verarbeiten zu lassen, können Web-Bilder bekannter Serveradressen auch mit Hilfe von Drag and Drop angelegt werden. Hier finden Sie ein vollständiges Beispiel, mit dem Bilder eines Adobe Experiance Managers (AEM) direkt in InDesign® platziert werden können.

Für die Platzierung von Web-Bildern im Bildrahmen werden folgende Regeln angewendet:

  1. Beim Anlegen von Web-Bildern mit Skriptfunktionen wie frame::image oder mit Hilfe von <w2inline>-Tags im TaggedText werden die im Aufruf angegebenen Platzierungshinweise (Position, Skalierung, ...) verwendet, egal ob der Zielrahmen bereits ein Bild enthält oder nicht.

  2. Beim manuellen Anlegen von Web-Bildern mit Hilfe des Menüs Bearbeiten -> Comet-Bild einfügen werden die Einstellungen eines bereits existierenden Bildes verwendet. Ist der Zielrahmen leer, wird das Bild zentriert in max. 100% Skalierung eingesetzt. Bilder, die größer als der Zielrahmen sind, werden entsprechend verkleinert.

  3. Beim Aktualisieren von Web-Bildern haben die Bildeinstellungen eines eventuell existierenden Bildes Vorrang. Lediglich ein evtl. Anpassen der Rahmengröße an die Bildgröße (i.A. durch ein negatives Alignment) wird ausgeführt. Achtung: Jedesmal, wenn das neue Bild kleiner wird, wird auch der Rahmen kleiner, aber größer wird er nie.

    Ist der Bildrahmen leer werden die Platzierungshinweise verwendet, mit denen das Web-Bild ursprünglich eingefügt wurde.

Folgende Protokolle werden für den Download der Bilder unterstützt:

Eventuell nötige Logindaten werden entsprechend der URL-Syntax angegeben, also etwa

http://paul:passwort@www.hi13.de/aaa.png

Passworte innerhalb der URLs werden im Dokument verschlüsselt und in ///*****/// eingeschloseen im Dokument hinterlegt und bei Bedarf automatisch entschlüsselt.

Auf Bilder, die von einem PubServer zur Verfügung gestellt werden, kann in der Regel nur über den REST Connector der Verbindung zugegriffen werden. Zum Laden dieser Bilder generiert das Content System des PubServers spezielle sogenannte Media Proxy URLs. Der erste Parameter dieser Media Proxy URLs heißt immer downloadUrl und enthält die URL-konform kodierte URL der Media-Daten (des Bildes).

Hier ein Beispiel einer korrekt formatierten Media Proxy URL:

https://pubserver.com/rest-connector/mediaproxy/example/myDownload/0815?downloadUrl=https%3A%2F%2Fpim.com%2Fimages%2F0815.png%3Fsize%3D480x640

Media-Proxies sind in der Regel vor unberechtigten Zugriffen geschützt und verlangen zur Authentifizierung eine gültige PubServer-SessionID. Beim Download von Web-Bildern aus Media Proxies wird deshalb automatisch die aktuelle SessionID als Cookie mit dem Namen PubServSessID mitgegeben. (Als Trick können Sie sich in einem anderen InDesign einloggen und die SessionID dieser Verbindung in die Datei $DESKTOP/sessionid.h schreiben. Dann wird diese SessionID verwendet.)

Besteht keine PubServer-Verbindung, wird der Download von Media Proxies abgelenht.

Achtung: Um Unklarheiten bei der URL-Kodierung von PubServer-URL und DownloadUrl zu vermeiden, darf die PubServer-URL (also der Teil der Media Proxy URL vor ?downloadUrl=http ) keine unkodierten URL-Sonderzeichen außer / und : enthalten!

Wird Ihr Internet-Zugang ganz oder teilweise über einen Proxy gesteuert, müssen die Proxyeinstellungen auch den Webbildern bekannt sein. Wählen Sie dazu das Flyout-Menü Proxy... der Palette Web-Bilder. Im erscheinenden Dialog können Sie die Proxydaten angeben. Die Proxyeinstellungen sind auch nach Neustart des Programmes aktiv. Die Adresse des aktiven Proxies wird hinter dem Menünamen Proxy | angezeigt.

Alternativ zum Proxy-Dialog kann der Proxy auch mit den folgenden Skriptfunktionen bearbeitet werden. Auch hier sind die gemachten Einstellungen neustart-resistent und gelten insbesondere auch nach Trennen der aktuellen Datenverbindung:

Bild-URLs können Session-IDs und andere zeitlich begrenzten Angaben enthalten. Hier ein Beispiel:

Die Bild-URL enthält den Parameter session, dessen Wert wird vom Server www.company.com geprüft wird. Ist die Session ungültig oder abgelaufen, liefert der Server das Bild nicht (mehr) aus:

https://www.company.com/service/object_image/get?id=...&session=8bed0851-dad5-41b5-bcca-c2b7d3e888dc&p2=12

Web-Bilder mit "flüchtigen" URLs haben damit also zwei Probleme:

  1. Wenn sich die URL ändert, wird das Bild bei jeder Prüfung als 'Verändert' erkannt.
  2. Wenn die URL fest bleibt, dann kann das Bild nicht aktualisiert werden.

Die Lösung ist naheliegend: Die flüchtigen Teile der URL müssen durch feste Angaben ersetzt werden, die beim Prüfen und/oder Laden des Bildes eine Neuberechnung der flüchtigen Teile ermöglichen. Zur Lösung haben wir eine neue "Funktion" eingeführt, mit der die flüchtigen Teile der URL bei Bedarf neu berechnet und ersetzt werden können:

getSessionData(name,attribute)

Der Name getSessionData ist fest. name und attribute werden so festgelegt, dass der ersetzte flüchtige Wert neu berechnet werden kann. Die Angabe erfolgt ohne Leerzeichen!

Die obige URL ändert sich also z.B. wie folgt:

https://www.company.com/service/object_image/get?id=...&session=getSessionData(paul,session)&p2=12

Am Rahmen des Web-Bild wird die jetzt unveränderliche Bild-URL gesichert. Soll das Bild geladen oder überprüft werden, wird zuerst getSessionData(name,attribute) neu berechnet und durch seinen aktuellen Wert ersetzt. Im Folgenden wird beschrieben, wie die Neuberechnung konfiguriert wird.

Für die Ermittlung des aktuellen Wertes von getSessionData muß zuerst der Server befragt werden. Dazu benötigen Sie zwei Dinge:

  1. Eine Login-URL loginURL.
  2. Die passenden Zugangsdaten credentials.

Diese Angaben müssen Sie bei der IT der Firma erfragen, die den Server der Bild-URL betreibt. Die erhaltenen Daten tragen Sie in die Datei sessions_data.xml ein. sessions_data.xml wird an den folgenden Stellen gesucht:

  1. $PREFS/werkii/sessions_data.xml
  2. $PLUGINS/sessions_data.xml
Die erste gefundene Datei wird verwendet.

Einträge für session-abhängige Werte müssen folgendes Format haben:

<sessions>
	<session>
		<name>Unique-Name<name>
		<url>https://www.priint.com/service/usermanagement/login<url>
		<data>
		{ 
			"username": "uname", 
			"password": "***", 
			"clientType": "Web", 
			"language": "de_DE", 
			"token": null, 
			"connectorName": "default" 
		}
		<data>
	<session>
	<!-- More Entries -->
<sessions>

Mit Hilfe dieser Daten kann Web-Bilder eine automatische Serveranfrage zusammenstellen und ausführen (lassen). In CURL-Notation entspricht die Anfrage der folgenden Terminal-Anweisung:

curl -X POST url -H "Content-Type: application/json" -d data

Die Server-Antwort auf diese Anfrage muß alle nötigen flüchtigen Daten enthalten. Als Antwortformat wird zwingend JSON erwartet!

Eine gültige Anwort könnte besipielsweise so aussehen:

{
    "session" : "ab96150a-36e3-4880-87fc-10d23644aaaa",
    "userId" : "03b83f47-0c76-426a-a2e5-b24c1c8a7c04",
    "language" : "de_DE",
    "message" : null,
    "code" : 0
}

Im einem zweiten Schritt wird mit Hilfe des Parameters attribute aus getSessionData der gewünschte aktuelle Wert des gegebenen Attributes ermittelt:

Mit der Angabe getSessionData(paul,session) in der Bild-URL erhalten wir aus der obigen Antwort den Wert ab96150a-36e3-4880-87fc-10d23644aaaa und die aktuell angewendete URL ändert sich wie folgt:

https://www.company.com/service/object_image/get?id=...&session=ab96150a-36e3-4880-87fc-10d23644aaaa&p2=12

Mit dieser URL kann das Bild jetzt geladen und geprüft werden. Zu einem späteren Zeitpunkt wird die URL automatisch neuberechnet werden.

Mitunter ist es nötig, einer URL weitere Informationen im sogenannten HTTP-Header mitzugeben. In curl-Notation entspricht das den Angaben der Option -H. Hierfür gehen Sie wie folgt vor:

  1. Anlegen der Header-Definition in sessions_data.xml
  2. Eintragen der Definition in die URL mit =getHeaderData(name)

Legen Sie für jede Sammlung benötigter HTTP-Header einen eindeutig benannten Eintrag in der Datei sessions_data.xml an. Die Einträge dürfen jeweils beliebig viele Header-Daten festlegen und müssen folgender Syntax haben:

<session>
	<name>myName</name>
	<header>headerData_1 OR ##actionID</header>
	...
</session>

Die Angabe kann entweder ein direkter Wert, also z.B. Content-Type: application/png sein oder die mit ## eingeleitete ID einer definierten Aktion Ihres Datenpools.

Achten Sie bitte darauf, dass bei Verwendung von Aktionen Ihre Bild-URL unterschiedliche (oder keine) Bilder laden wird, wenn Sie die Datenverbindung trennen!

Folgende Variablen Sind in dem cSkript definiert:

Variable Art Typ Beschreibung
gURL r/o char*

Aktuelle URL

gName r/o char*

Name der Header-Daten

gHeaderData w StringList Ergebnisliste. Tragen Sie in diese Liste alle gewünschten Header-Daten ein.

Hier ein Beipiel eines cSkriptes:

#pragma plain

#include "internal/types.h"

int main ()
{
    wlog ("", "___UU (%s)\n", gURL);
    wlog ("", "___NN (%s)\n", gName);
 
    stringlist::append (gHeaderData, "AAA: aaa");
    stringlist::append (gHeaderData, "BBB: bbb");
 
    return 0;
}

Dieses Script kann auch ein Python Skript sein. Nähere Informationen finden Sie hier.

Hier ein Beipiel eines Python Skriptes:

#!py
#pragma plain

import comet

def main():
    comet.wlog(f'___UU ({comet.gURL})')
    comet.wlog(f'___NN ({comet.gName})')

    comet.setOutput('gHeaderData', ['AAA: aaa', 'BBB: bbb'])

    return 0

Fügen Sie für jede benötigte Sammlung von HTTP-Headerdaten an beliebiger Stelle aber in genau dieser Schreibweise und ohne weitere Leerzeichen folgende Angabe ein:

=getHeaderData(myName)

Hier ein Beispiel:

http://www.hi13.de/aaa.png=getHeaderData(pp)
   
oder auch
http://www.hi13.de=getHeaderData(pp)/aaa.png

InDesign® erwartet, dass Bilder als lokale Dateien existieren. Erlaubt sind vollständige Pfade innerhalb des lokalen Netzwerkes und Bildpfade 'neben' dem Dokument. Bilder aus Ordnern neben dem Dokument können von InDesign® auch in anderen Netzwerken gefunden werden, wenn dort neben dem Dokument die gleichen Bildordner liegen. Verknüpfungen zu Bildern 'oberhalb' eines Dokumentes können in anderen Netzen nur bei der Verwendung von UNC-Pfaden wieder aufgelöst werden!

Bilder außerhalb des lokalen Netzwerkes werden von InDesign nicht unterstützt. (Aber das macht ihr Browser ja auch nicht, der muß sich ja jedes Bild auch erstmal laden.) Um Web-Bilder zu unterstützen, müsssen wir die Bilder also zuerst einmal lokal downloaden. Folgende Möglichkeiten zur Bildablage werden dabei unterstützt:

Die Download-Pfade der Bilder dürfen inklusive Datennamen nicht länger als 260 Zeichen werden! Hinweis: Bei längeren Pfaden können Sie mit Hilfe der NAMEFLAGS des lokalen Namens versuchen, den Namen der Download-Datei zu kürzen.

Ab v4.3 R35410 werden beliebig lange und nur vom jeweiligen Betriebssystem begrenzte Pfade unterstützt. Trotzdem dürfen die Namen der Download-Dateien nicht länger als 255 Zeichen sein. Würde der Download-Name auch nach Anwendung eventueller ////-Hinweise länger als 255 Zeichen werden, wird automatisch der MD5-Hash der originalen URL plus _name_too_long plus einer eventuellen Dateiendung verwendet.

Als Standardordner für den Download wird der Ordner

DoumentName_Links

direkt neben dem Dokument verwendet. Existiert der Ordner nicht, wird er automatisch angelegt.

Damit relative Bildverweise funktionieren können, muss das Dokument einen Pfad haben. Neue Dokumente müssen also mindestens einmal gesichert worden sein!

Im Panelstatement 141 einer priint:comet Konfiguration kann ein Skript hinterlegt werden, das zu einer gegebenen URL den Ablageordner der Bilddatei berechnet. Gibt das Skript einen Leerstring zurück, wird das Bild relativ neben dem Dokument abgelegt.

Variable Datentyp Typ Beschreibung
gDestFolder String out

Trage Sie hier den gewünschten Zielpfad ein. Beachten Sie bitte, dass Variable ist vom Typ String ist, und nicht char*!

  • "" : Verwende den Standardordner filename_links relativ neben dem Dokument
  • Sonst : Gültiger und kompletter Ordnerpfad für den Download des Bildes. Der Pfad darf mit einem definierten $-Alias beginnen. Existiert der Ordner nicht, wird er - wenn möglich - automatisch angelegt.
gURL char* in

Vollständige URL des Bildes

gDestName char* in

Lokaler Name der Bilddatei

gDocumentID char* in

Dokument-ID des aktuellen Dokumentes

Hinweis: Die Dokument-ID wird mitgegeben, um Ihnen die Arbeit zu erleichtern. Name und Pfad des Dokumentes können Sie mit den Skriptfunktionen document::name und document::path leicht bestimmen.

Hier ein sehr einfaches Skript zum Festlegen eines globalen Bildordners für Web-Bilder

int main ()
{
    if (!system::is_server ()) string::set (gDestFolder, "/Volumes/Images");
    else string::set (gDestFolder, "/Volumes/Images_%s", server::get_session_arg ("-configuration"));
    return 0;
}

Ab v4.3 R36308 können Sie auch einen gemeinsamen Dowwload-Ordner für alle Instanzen verwenden. Mehr dazu siehe hier.

int main ()
{
	string::set (gDestFolder, "/Volumes/Images");
    prefs::webimage_enable_locks (1);

    return 0;
}

Ist nichts anderes angegeben, wird der MD5-Hashcode der Bild-URL als Dateiname für den Download verwendet. Zusätzlich wird hinter Domain und Pfad der Bild-URL nach einem Namenszusatz für das Bild gesucht. Wird ein Name gefunden, wird er (durch _ getrennt) an den Hashcode angefügt und als Anzeigename in der Palette Web-Bilder verwendet.

Namen heruntergeladener Web-Bilder haben also in der Regel keine oder möglicherweise sogar falsche Dateiendungen.

Die Namensvergabe mit Hashcodes hat zwei Gründe:

Die in den URLs gefundenen Bildnamen können oft recht technisch oder lang sein. Und fehlende oder unpassende Dateiendungen sind zwar für die Bilddarstellung in den Plugins und in InDesign® kein Problem, können aber die Verwendung in Drittprogrammen beeinträchtigen. Hier ein Screenshot der Namen zwei solcher URLs:

Um diese Probleme zu verhindern, können Sie hinter der eigentlichen Bild-URL Zusatzangaben zu Anzeige- und Dateinamen machen. Fügen Sie dazu am Ende der URL den Trenner //// an. Nach dem Trenner können Sie eigene Anzeige- und Dateinamen festlegen. Für das Laden der Bilddateien werden diese Angaben entfernt. Folgende allegemeine Syntax wird erwartet:

    url////displayName
  | url////--fileNameOptions
  | url////displayName--fileNameOptions

Die folgende Tabelle beschreibt die Angaben im Einzelnen:

URL Anzeigename Dateiname Bemerkungen
http://www.hi13.de/schnipp schnipp

163...f8_schnipp

Am Ende der URL wurde ein Name gefunden. Der gefundene Name wird durch _ getrennt an den MD5-Hashcode der URL angefügt. Aber da der Name keine Dateiendung hat, bleibt die geladene Datei ebenfalls ohne Endung und die Verwendung der Bilddatei in Drittprogrammen ist möglicherweise eingeschränkt.

Im Folgenden wird immer die gleiche URL http://www.hi13.de/schnipp verwendet.
...////My Title My Title 163...f8_schnipp

Der direkt hinter dem Trenner //// folgende Text wird als Anzeigename in der Palette verwendet. Hier finden Sie weitere Informationen zu Anzeigenamen.

Der Name der Bilddatei ist von dieser Angabe unbetroffen und bleibt daher in diesem Fall weiter ohne Dateiendung.

Mit '--' getrennte Angaben der ////-Defintion werden zur Bestimmung der Download-Datei verwendet.
...////--NAMEFLAGS schnipp bei kNoHash z.B.: schnipp

bei kOnlyHash z.B.: 163...f8

Benutze den Namen, der in der URL gegeben ist. Als Name wird der Teil hinter dem letzten / der URL verwendet. Folgende Schlüsselwörter werden unterstützt:

  • [+]kEllipsize~ : Lange Namen werden auf 52 Zeichen gekürzt. Die Kürzung erfolgt nur im Basisnamen des Dateinamens. Die Dateiendung bleibt erhalten. Durch ? getrennte URL-Parameter werden entfernt Kürzungen werden durch drei Punkte (...) ersetzt.
    • kEllipsizeStart : Am Anfang kürzen
    • kEllipsizeMiddle : In der Mitte kürzen
    • kEllipsizeEnd : Am Ende kürzen

  • [+]kNoHash Den Hash-Code der Gesamt-URL nicht dem (mglw. gekürzten) Namen voranstellen. In diesem Fall müssen Sie selbst für die Eindeutigkeit der Dateinamen sorgen!

  • kOnlyHash [seit v4.3 R33870] Nur den Hashcode und die Dateiendung der URL als Namen der Download-Datei verwenden. Dateiendungen länger als 10 Zeichen werden ignoriert.

Der Anzeigename darf leer sein. Dann folgt der Trenner '--' direkt dem '////' am Ende der URL.

...////--gif[NAMEFLAGS] schnipp.gif 163...f8_schnipp.gif

Ändern/Anfügen einer Dateiendung. Die Endung wird an den Anzeigenamen angefügt. Zusätzlich dürfen die oben beschriebenen Flags zur Verkürzung des Dateinamens angefügt werden, also z.B ////--gif+kNoHash.

Der Anzeigename darf leer sein. Dann folgt der Trenner '--' direkt dem '////' am Ende der URL.

...////My Title--gif[NAMEFLAGS] My Title 163...f8_schnipp.gif

Ändern von Anzeigename und Dateiendung. Zusätzlich dürfen die oben beschriebenen Flags zur Verkürzung des Dateinamens angefügt werden, also z.B ////My Title--gif+kNoHash.

Der Anzeigename darf leer sein. Dann folgt der Trenner '--' direkt dem '////' am Ende der URL.

...////My Title--!myImage.gif My Title myImage.gif

Ändere den Anzeigename und den Dateinamen der Bilddatei. In diesem Fall müssen Sie selbst für die Eindeutigkeit der Dateinamen sorgen!

Mit '--!' ändern Sie den gesamten Dateinnamen der geladenen Bilddatei.

...////My Title--!A/B/myImage.gif My Title myImage.gif

Vor dem Dateinamen darf ein relativer Pfad angegeben werden. Das Bild wird dann im angegebenen Unterordner das aktuellen Downloadordners abgelegt. In diesem Fall müssen Sie selbst für die Eindeutigkeit der Dateinamen sorgen!

Der Teilpfad darf keine ..-Ordner enthalten. Existiert der Ordner noch nicht, wird er automatisch angelegt.

...////My Title--!/A/B/myImage.gif My Title myImage.gif

Vor dem Dateinamen darf ein absoluter Pfad angegeben werden. Das Bild wird dann im angegebenen Ordner abgelegt (und nicht im aktuellen Standard-Download!). Der Pfad darf mit einem definierten Alias beginnen. In diesem Fall müssen Sie selbst für die Eindeutigkeit der Dateinamen sorgen!

Sie benötigen die entsprechenden Schreibberechtigungen! Existiert der Ordner noch nicht, wird er automatisch angelegt.

Allgemein gilt für die Angaben:

[Ab v4.3 R36308] Arbeiten mehrere Instanzen von InDesign®-Server und/oder comet_pdfs gleichzeitig und sollen alle den gleichen Download-Ordner verwenden, wird es zwangsläufig passieren, dass zwei verschiedenen Prozesse gleichzeitig die gleiche Downloaddatei schreiben wollen. Das wird natürlich nicht gehen. Um solche Konflikte zu verhindern, können die Downloads die Zieldatei für alle konkurrierenden Prozesse des gleichen Rechners solange sperren, bis die eigene Zieldatei fertig ist. Alle anderen Prozesse, die die gleiche Datei schreiben wollen, müssen auf das Ende der Sperre warten. Erst danach laufen diese Prozesse automatisch weiter. In den meisten Fällen, nämlich dann, wenn der erste Download erfolgreich war, können diese Prozesse dann ohne weitere Downloads auf die Zieldatei zugreifen. Sie sparen mit dem automatischen Sperren der Zieldateien also nicht nur viel Plattenplatz, sondern auch Zeit.

Aus Gründen der Rückärtskompatibilität ist das Sperren der URL-Downloads nicht automatisch aktiviert. Mit folgender Anweisung z.B. im After-Login Skript (Panelstatement 92) können Sie das automatische Sperren aktivieren:

prefs::webimage_enable_locks (1);

Folgende Skriptbefehle für das Sperren der URLLink-Downloads stehen zu Verfügung:

Zu jeder URL werden vom Server auch sogenannte Header-Informationen bereitgestellt. Diese Infos enthalten üblicherweise Angaben zum Dateidatum, der Größe der Datei und meist ein sogenanntes ETag. Header-Infos sind meist nicht länger als 500-1000 Bytes. Wird eine URL serverseitig geändert, werden (hoffentlich) auch die Headerinfos entsprechend angepasst.

Beim Laden eines URL-Bildes vom Server werden vor den eigentlichen Bilddaten aurtomatisch die aktuellen Header-Infos geladen. Um den aktuellen Status zu prüfen, genügt es dann, lediglich die aktuellen Header-Infos zu holen und mit den hinterlegten Daten zu vergleichen.

Folgende Daten der Header-Informationen werden zum Vergleich verwendet:

Die Suche erfolgt case insensitive. Ein heruntergeladenes Bild wird als geändert angesehen, wenn mindestens eine der oben genannten Informationen einen anderen Wert hat als zum Zeitpunkt des Download. Sind alle Informationen leer, werden Bilder immer als geändert angesehen (und beim Aktualisieren jedesmal neu geladen!).

Es werden keine Binärvergleiche der Bilder gemacht. Manuelle Änderungen an den lokalen Bildern beeinflußen den Status eines URL-Bildes nicht!

Die Header-Infos der Bilder werden im Unterordner etags des jeweiligen Downloadordners der Bilder hinterlegt. Dort wird für jedes geladene Bild eine Datei gleichen Namens mit der Endung txt abgelegt, die die Header-Infos zum Zeitpunkt des Downloads enthält. Beim Aktualisieren eines Bildes wird die ETAG-Datei ebenfalls aktualisiert.

Fehlt die Datei mit den Header-Infos, wird ein Bild automatisch als "Geändert" angesehen und beim nächsten Aktualisieren automatisch neu geladen.

Es genügt leider nicht, die Headerdaten im jeweiligen Bildrahmen zu hinterlegen. Stellen Sie sich folgende Situation vor:

  1. Bild A wird geladen
  2. Der Rahmen mit Bild A wird gelöscht (oder mit einem anderen Bild verknüpft)
  3. Bild A wird auf dem Server verändert zu A'
  4. Ein neuer Rahmen wird Bild A verknüpft.

Jetzt gibt es zwei Möglichkeiten:

Eingebettete Bilder werden wie normale Bilder zuerst vom Server geladen. Nachdem das heruntergeladene Bild eingebettet wurde, wird es jedoch automatisch sofort wieder gelöscht. Die Headerdaten werden in diesem Fall direkt im Bildrahmen hinterlegt.

Hat das aktualisierte Bild die gleichen Proportionen wie das aktuell eingebettete Bild, werden die lokalen Geometrieänderungen am Bild (Bildposition, Drehung, Skalierung, Scherwinkel) wiederhergestellt. Bei geänderten Seitenverhältnissen wird das Bild mit dem ursprünglichen Platzierungshinweis (link-oben, oben-mitte, ...) platziert. Bilder, die mit der gleichen Adresse (URL) eingebettet wurden, bleiben bei Aktualisierungen eines Bildes unverändert.

Hinweis: Um möglichst geringen UPLOAD-Traffic zu haben, sollten eingebettete Web-Bilder vor dem Versenden der InDesign®-Dokumente gelöscht und erst am Zielort (jetzt mit Download-Geschwindigkeit) wieder geladen werden.

Beim Öffnen eines Dokumentes werden automatisch alle im Dokument enthaltenen Web-Bilder überprüft: Fehlt die lokale (heruntergeladene) Bilddatei, bekommt der Bildrahmen den Status Unbekannt (blau). Aus Performancegründen wird nicht geprüft, ob die lokale Datei noch aktuell ist und fehlende Bilder werden nicht automatisch geladen. Das Gleiche gilt für Copy/Paste und das Platzieren von Snippets. Auch hier wird aus Performancegründen lediglich überprüft, ob die lokale Bilddatei vorhanden ist.

Beim Drag and Drop zwischen geöffneten Dokumenten wird keine Prüfung der Web-Bilder vorgenommen!

Beachten Sie bitte, dass auch beim Einsetzen von Templates beim Produktaufbau u.ä. die Web-Bilder des Templates nicht automatisch nachgeladen werden. Wenn Ihre Templates statische Web-Bilder enthalten, müssen diese Bilder bei Bedarf mit geeigneten Skriptfunktionen oder manuell nachgeladen werden.

Die folgende Aufzählung enthält alle cScript-Funktionen zur Bearbeitung von Web-Bildern.