[Since Comet 4.0.5 R20002] Images in InDesign® must be either available in the local network or embedded into the document. Images located in the internet can not be processed by InDesign®. With the plug-in URL Link and its panel Web Images the priint:comet plug-ins offer a possibility to use images from the net too. To do this, images are downloaded locally first and links are made to these files then.

Attention : Despite all efforts, it may happen that URLs cannot be resolved. Non-resolvable URLs are not subject of the WERK II support! Please feel free to contact our support in these cases, but please understand that we treat enhancements in this area as (chargeable) feature requests.

In order to keep connected, the frames will remember the URL and its Header information. This allows updating the images if they have been changed on server side.

Please pay attention to property rights and licenses of the used images.

In the panel Web Images all Web images are shown together with the frames, using these images:

The states of the images are displayed by the cloud symbol:

Using the menu View -> Web Image State you can also display the states of the images at the document frames:

By double-clicking on the cloud symbols of the panel, current images (green) are checked again and changed images (orange) are reloaded.

Single clicking the page number selects the frame in the document. The following additional options are supported:

Using the fly out menus of the panel, the document's web images can be checked, updated and deleted. Individual images can be edited using the Web Images context menu.

To avoid unnecessary network traffic, status checks of the Web Images are only made on user requests. An automatic check is not made. With timer::document_start in the AfterLogin script (panel statement 92) you can easily configure an automatic check by yourself. Use document::check_url_links in the idle timer action to check the Web Images.

The data required for the Web Images can be displayed in the panel Plug-Ins -> Comet Admin -> Frame Tags. To do so, hold down the SHIFT key and click on the magnifying glass in the upper right corner of the panel.

Using the default location for image download requires, that the document has to by saved once at least. See here for more informations.

To manually create a Web Image, proceed as follows:

The cScript function frame::image, image placeholders and the TaggedText-Tags <in>, <w2inline> and <graphicell> automatically checking the given image paths. If they see an URL, they creating Web Images by default.

Using URL events, you may configure your system in a way, that well known URL drop downs will create Web Images. A complete example you will find here.

The following protocols are supported for downloading images:

Possibly required login data are specified according to the URL syntax, e.g.


Passwords within the URLs are stored encrypted and enclosed by /// into the document and are automatically decrypted if required.

Images provided by a PubServer can usually only be accessed via the connection's REST Connector. To load these images, the Content System of the PubServer generates special so-called Media Proxy URLs. The first parameter of these Media Proxy URLs is always called downloadUrl and contains the URL conform encoded URL of the media data (the image).

Here is an example of a correctly formatted Media Proxy URL:


Media Proxies are usually protected against unauthorized access and require a valid PubServer SessionID for authentication. When downloading Web Images from Media Proxies, the current sessionID is therefore automatically included into the call as the named cookie PubServSessID. ((As a trick, you can log in into another InDesign and write the SessionID of that connection into the $DESKTOP/sessionid.h file. Then this SessionID will be used).)

If there is no PubServer connection, the download of Media Proxies will fail.

Attention: To avoid errors in the URL encoding of PubServer URL and DownloadUrl, the PubServer URL (i.e. the part of the Media Proxy URL before ?downloadUrl=http ) must not contain any unencoded URL special characters except / and :!

If all or part of your Internet access is controlled by a proxy, the proxy settings must also be known to the Web Images. To do this, select the Proxy... flyout menu of the Web Images panel. In the dialog that appears, you can specify the proxy settings. The proxy settings are active even after restarting the program. The address of the active proxy is displayed behind the Proxy | menu name.

As an alternative to the Proxy Dialog, the proxy can also be edited with the following script functions. Here, too, the settings made are restart-resistant and active in particular even after the current data connection is disconnected:

Image URLs can contain session IDs and other time-limited information. Here is an example:

The image URL contains the session parameter, whose value is checked by the server www.company.com. If the session is invalid or expired, the server does not deliver the image (anymore):


So Web Images with "volatile" URLs have two problems:

  1. If the URL changes, the image will be detected as 'Changed' on each check.
  2. If the URL remains fixed, then the image cannot be updated.

The solution is obvious: The volatile parts of the URL must be replaced with fixed information that allows recalculation of the volatile parts whenever the image is checked and/or loaded. To solve this, we have introduced a new "function" that allows the volatile parts of the URL to be recalculated and replaced as needed:


The specification is done without spaces! The name getSessionData is a keyword. name and attribute are set so that the replaced volatile value can be recalculated. How this is done is described below.

So, for example, the URL above changes as follows:


As the Web Image of the frame the new and unchangeable image URL is saved. But when the URL is applied while checking or loading the image, getSessionData(name,attribute) is automatically replaced with its current value. This solves both of the above problems. Below you will learn how to configure the recalculation.

To get the current value of getSessionData, you must first query the server. For this you need two things:

  1. The Login-URL loginURL.
  2. The matching access data credentials. Credentials must be formatted as JSON!

You must ask for this information from the IT of the company that operates the server of the image URL. Enter the received data into the file

$PREFS/sessions_data.xml resp. $PLUGINS/sessions_data.xml

The new entry gets the name you used in the definition of getSessionData. (In the above example, paul.) Names must be unique.

The file must have the following format:

    <!-- More Entries -->

Here is an example of a credential. Passwords are usually encrypted here.

	"username": "demo", 
	"password": "****", 
	"clientType": "Web", 
	"language": "en_US",
	"token": null,
	"connectorName": "default" 

Using this data, Web Images can assemble and send an automatic server request. In CURL notation, the request corresponds to the following Terminal statement:

curl -X POST loginURL -H "Content-Type: application/json" -d credentials

The server response to this request must contain all necessary volatile data. The response format must be JSON!

A valid answer could look like this:

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

In the second step, the desired current value of the given attribute is determined with the help of the attribute parameter from getSessionData.

By specifying getSessionData(paul,session) in the image URL, we get the value ab96150a-36e3-4880-87fc-10d23644aaaa from the above response and the currently applied URL changes as follows:


This URL can be used to check and load the image now. And at any later time it will be recalculated automatically.

Sometimes it can necessary to add further information to a URL in the so-called HTTP header. In curl notation, this corresponds to the -H option. To do this, proceed as follows:

  1. Define the header data in sessions_data.xml
  2. Insert the definition into the URL using =getHeaderData(name)

Create a uniquely named entry in the sessions_data.xml file for each collection of required HTTP headers. The entries may each specify any amount of header data and must have the following syntax:

    <header>headerData_1 OR ##actionID</header>

The specification can be either a direct value, e.g. Content-Type: application/png or an actionID of your data pool given by a trailing ##.

Please note that if you use actions, your image URL will load different (or no) images when you disconnect the data connection!

The following variables are defined in the script:

Variable Kind Type Description
gURL r/o char*

Current URL

gName r/o char*

Name of Header data

gHeaderData w StringList Results list. Enter all the header data you want in this list.

Here's an example of a script:

#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;

This script may also be a Python Script. More information can be found here.

Here's an example of a Python script:

#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

For each required collection of HTTP header data, insert the following pseudo function at any location but in exactly this notation and without any additional spaces:


Here's an example:

or (e.g.)

InDesign® expects images to exist as local files. Permitted are global (i.e. complete) paths within the local network and image paths relative to the document. Images from the web must therefore always be downloaded from the network and stored locally.

Web-Images can be placed by the plug-in in the following locations:

The download paths including file names of the images must not be longer than 260 characters!

Note: For longer paths, you can try to shorten the name of the download file using the NAMEFLAGS of the Customized Name.

The only unique and always available relative location to a document is a folder directly next to the document. We are using the folder:


For relative image references to work, the document must have a path. The document must therefore have been saved at least once!

Using panelstatement 141 you can provide a script that calculates a path for the download folder according to a given URL. If the

Variable Typ Description
gDestFolder String

String for result path.

If empty, the relative path is used. Otherwise it must contain a valid complete path. Missing folders are created automatically.

Please note that gDestFolder is of type String, not char*!

gURL char*

Complete URL of Web Image

gDocumentID char*

Document ID of current document

Hint: The document Id is for your convenience. To get name and path of the document, please use document::name and document::path.

gDestName char *

Name of local download

Here's an very simple example:

int main ()
    string::set (gDestFolder, "/Volumes/Images");
	return 0;

If nothing else is specified, the MD5 Hash Code of the image URL is used as the file name for the download. In addition, a Name Suffix for the image is searched for after the domain and path of the image URL. If a 'name' is found, it is appended to the hash code (separated by _) and used as the Display Name in the Web Images panel too.

Names of downloaded Web Images usually have no or possibly even wrong file extensions.

There are two reasons for the naming with hash codes:

The image names found in the URLs can often be quite technical or long. In addition, missing or inappropriate file extensions, while not a problem for image rendering in the plugins and InDesign®, can interfere with use in third-party programs. Here is a screenshot of the names of two such URLs:

To avoid these problems, you can add display and file name information to your actual image URL. To do this, add the separator //// at the end of the URL. After the separator, you can specify your own display and file names. These specifications are removed for loading the image files. The following general syntax is expected:

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

The following table describes the information in detail:

URL Display Name File Name Remarks
http://www.hi13.de/schnipp schnipp


A name was found at the end of the URL. The found name is appended to the MD5 hashcode of the URL separated by _.

But please take care : Since the name has no file extension, the loaded file also remains without extension and the use of the image file in third party programs may be restricted.

The same URL http://www.hi13.de/schnipp is always used in the following descriptions.
...////My Title My Title 163...f8_schnipp

The text that follows directly after the //// separator is used as the Display Name in the Web Images panel. Here you can find more information about the Display Names.

The name of the image file is left untouched by this specification and therefore remains in this case without file extension.

Details of the //// definition separated by '--' are used to determine the download file.
...////--NAMEFLAGS schnipp for example for kNoHash : schnipp

for example for kOnlyHash : 163...f8

Use the name given in the URL. The part after the last / of the URL is used as the name. The following keywords are supported:

  • [+]kEllipsize~ : Longer names shortened to 52 letters. The shortening is only in the base name of the file name only. The file extension remains unchanged. URL parameters separated by ? are removed. Shortenings are marked by three points (...).
    • kEllipsizeStart : Shorten at the beginning
    • kEllipsizeMiddle : Shorten in the middle
    • kEllipsizeEnd : Shorten at the end

  • [+]kNoHash Do not prepend the hash code of the overall URL to the (possibly shortened) name. In this case you must ensure the uniqueness of the file names yourself!

  • kOnlyHash [since v4.3 R33870] Only use the hash code and the file extension of the URL as the name of the download file. File extensions longer than 10 characters are ignored.

The display name may be empty. In this case the separator '--' directly follows the '////' at the end of the URL.

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


Change/Append the file extension only. The given extension is appended to the display name too. In addition, the flags described above may be added to shorten the filename, e.g. ////--gif+kNoHash.

The display name may be empty. In this case the separator '--' directly follows the '////' at the end of the URL.

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

Change display name and file extension. In addition, the flags described above may be added to shorten the filename, e.g. ////My Title--gif+kNoHash.

The display name follows directly after the //// separator. Then, delimited by '--' from the display name, the file extension follows.

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

Change both, the display name and the filename of the image file. In this case you must ensure the uniqueness of the file names yourself!

Using '--!' you change the complete name of the downloaded image file.

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

A relative path may be specified before the filename. The image is then placed in the specified subfolder of the current download folder. In this case you must ensure the uniqueness of the file names yourself!

The subpath must not contain any .. folders. If the folder does not exist yet, it will be created automatically.

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

An absolut path may be specified before the filename. The image will then be placed in the specified folder (and not in the current default download!). The path may start with a defined $alias.. In this case you must ensure the uniqueness of the file names yourself!

You need the appropriate write permissions! If the folder does not exist yet, it will be created automatically.

In general, the following applies to the names:

For each URL, the server also provides so-called header information. These headers usually contain information about the file date, the size of the file and usually a so-called ETag. Header information are usually no longer than 500-1000 bytes. If a Web Image is changed on server side, the header information will be adjusted accordingly.

When loading a Web Image from the server, the current header information are loaded in addition to the actual image data automatically. In order to check the current state, it isenough to download the current header information only and compare them with the stored header information.

The following header information data is used for comparison:

The search is case insensitive. A downloaded image is considered modified if at least one of the above information has a different value than at the download time. If all information is empty, images are always considered changed (and reloaded each time when updating!).

No binary comparisons of the images are made. Manual changes to the local images do not affect the status of a Web Image!

Header information are stored in the sub folder etags of the image downloads. If the header information are missing, the image is downloaded always.

Unfortunately, it is not sufficient to store the header data in the respective image frame. Imagine the following situation:

  1. Image A is loaded
  2. The frame with image A is deleted (or linked with another image).
  3. Image A is changed to A' on the server.
  4. A new frame will be linked to image A.

Now there are two ways:

Embedded images are loaded from the server just like normal images. But after the downloaded image is embedded, however, it is automatically deleted immediately. Header information are stored in the frame itself.

If the updated image has the same proportions as the currently embedded image, the local geometry changes are restored on the image (image position, rotation, scaling, skew angle). When the aspect ratio is changed, the image is placed with the original placement guide (left-top, top-center, ...). Other images embedded with the same URL will not updated.

Note: In order to have the lowest possible UPLOAD traffic, embedded Web Images should be deleted before the InDesign® documents are sent, and be reloaded at the destination (now with download speed).

When opening a document, all Web Images contained in the document are automatically checked: If the local (downloaded) image file is missing, the image frame gets the state Unknown (blue). For performance reasons, the system does not check whether the local file is still up-to-date and missing images are not loaded automatically. The same applies to copy/paste and snippet placements. Here too, the system only checks whether the local image file is available.

When dragging and dropping between open documents, no Web Image checking is performed!

Please note that even when inserting templates during product build ups etc., the Web Images inside the templates are not automatically reloaded. If your templates contain static Web Images, these images must be reloaded as needed by using appropriate script functions or manually.

The following functions are implemented to support Web Images: